# architect Bien diseñado (well-architected) - Full Documentation > Lea sobre nuestras programaciones de actualizaciones [aquí](/docs/architect/es-mx/well-architected/guide/contributors). ## Introducción Una solución de Salesforce **adaptable** evoluciona con el negocio. Una solución bien diseñada para ser **adaptable** es resiliente y componible. Las soluciones **resilientes** gestionan bien los cambios.
Las soluciones **componibles** se ajustan rápidamente y con mayor estabilidad. La necesidad de cambio de negocio puede provenir de muchos orígenes: solicitudes de clientes, interrupciones del mercado o la industria u oportunidades de transformación digital. A veces los cambios son pequeños. A veces, los cambios son profundos. En los niveles más profundos, un cambio puede requerir que los negocios replanteen y cambien sus razones principales para operar y reevalúen el qué, cómo y dónde de sus ofertas de clientes. Las arquitecturas que son **adaptables** no solo ayudan a los negocios a sobrevivir y recuperarse de las interrupciones, sino que crean el potencial para que los negocios innoven y prosperen en tiempos de cambios profundos. La creación de sistemas **adaptables** requiere un pensamiento arquitectónico creativo y preciso. Debe comenzar con una comprensión precisa de la trayectoria a corto y largo plazo del negocio. A medida que evalúa detalles de implementación individuales, debe tener en cuenta las repercusiones a lo largo de múltiples dimensiones y niveles de detalle. Hay que pensar en términos de personas, procesos y tecnología. Además, debe predecir simultáneamente impactos a nivel macro y micro, para el estado actual y cualquier estado futuro. Las siguientes secciones proporcionan directrices más detalladas para cada uno de los comportamientos principales de una arquitectura de soluciones **adaptable**. ## Descripción general adaptable

Resistente
Las soluciones resilientes gestionan bien los cambios. Las arquitecturas resilientes pueden volver al comportamiento y las operaciones esperados rápidamente y de formas predecibles.
Gestión del ciclo de vida de las aplicaciones	Respuesta de incidentes	Planificación de la continuidad
Gestión de versiones Estrategia medioambiental Estrategia de prueba	Tiempo de recuperación Capacidad de triaje Monitoreo y alerta	Continuidad de negocio Continuidad de la tecnología
Componible
Las soluciones componibles se ajustan rápidamente y con mayor estabilidad. Las arquitecturas componibles están construidas en unidades que funcionan correctamente entre sí y se pueden intercambiar dentro y fuera de servicio.
Separación de preocupaciones	Interoperabilidad	Capacidad de empaquetado
Unidades funcionales Gestión de estado	Mensajería y eventos Gestión de API	Acoplamiento suelto Gestión de dependencias

> Lea sobre nuestras programaciones de actualizaciones [aquí](/docs/architect/es-mx/well-architected/guide/contributors). ## Introducción Los sistemas demuestran un comportamiento automatizado permitiendo al negocio cumplir objetivos y metas clave de forma más rápida y a escala. La automatización saludable permite a los usuarios centrarse en trabajo de alto valor y reduce el tiempo empleado en tareas manuales repetitivas o entrada de datos compleja. La mayoría de las veces, la automatización significa traducir procesos de negocio de un formulario a otro: de formulario en papel a formulario digital, de un sistema antiguo a uno nuevo. Con cada traducción de procesos de negocio llega una oportunidad para la transformación. La transformación no consiste en utilizar nuevas tecnologías para introducir cambios perturbadores y confusos para los usuarios. La transformación consiste en crear formas más sencillas de realizar el trabajo, permitiendo que el negocio crezca sin fricciones y empoderando a los usuarios de negocio para centrarse más en lo que realmente importa a sus partes interesadas. Desde un punto de vista arquitectónico, esto implica identificar tareas que se pueden eliminar por completo o gestionar automáticamente. Requiere una conexión clara entre cómo se utiliza la tecnología y su impacto mensurable en el negocio. Algo importante a tener en cuenta sobre la automatización con Salesforce: se puede realizar con una variedad de herramientas, utilizando conjuntos de habilidades programáticas y declarativas. Diseñar automatizaciones bien arquitectadas no se trata de elegir construir solo con una herramienta de automatización. Se trata de utilizar enfoques coherentes y predecibles, y permitir a los equipos desarrollar, probar, implementar y mantener las automatizaciones que diseña. Sus automatizaciones deben adoptar la forma más [mantenible y legible](/docs/architect/es-mx/well-architected/guide/intentional) posible. Esta sección trata cómo diseñar y refactorizar automatizaciones para permitir a los negocios cumplir objetivos clave de forma más rápida y a escala. Puede mejorar la arquitectura de sus automatizaciones en Salesforce centrándose en la eficiencia y la integridad de los datos. ## Eficiencia La creación de eficiencia en sus automatizaciones no se trata de volver a crear negocio como siempre con tecnologías de Salesforce. Se trata de comprender profundamente las mediciones clave y los resultados de negocio de los que los equipos serán responsables de reunirse o realizar un seguimiento, y retroceder para ver [unidades funcionales](/docs/architect/es-mx/well-architected/guide/composable#unidades-funcionales) dentro y entre el trabajo que está automatizando. Se trata de identificar cómo puede crear patrones con sus automatizaciones que permiten al negocio operar de forma más efectiva y rápida, a escala. La lógica de automatización eficiente hará que sus sistemas: - Más ampliable y valioso para el negocio - Más útil para usuarios - Más [adaptable](/docs/architect/es-mx/well-architected/guide/adaptable-overview) y capaz de satisfacer necesidades de negocio en evolución Puede mejorar la eficiencia en sus automatizaciones a través del diseño de procesos y la lógica operativa. ### Diseño de procesos El diseño de procesos implica definir las formas en que se realiza el trabajo. Construir procesos verdaderamente eficientes y efectivos significa que sus diseños no solo replican formas actuales de trabajo. Identificar y eliminar pasos ineficaces o poco claros es esencial. Los procesos optimizados deben crear valor de negocio mensurable (consulte [KPI](/docs/architect/es-mx/well-architected/guide/automated#kpis)) sin pasos innecesarios. Los pasos no claros o innecesarios probablemente crearán deudas técnicas y darán como resultado automatizaciones inmantenibles. A menudo, la responsabilidad de descubrir y documentar procesos de negocio recaerá en un analista de negocio o incluso un administrador del sistema. Los arquitectos son responsables de asociarse con estos miembros de su equipo para asegurarse de que sus diseños de procesos son técnicamente sólidos y están bien estructurados. Aplicar su Knowledge de la plataforma Salesforce lo antes posible ayudará a su equipo a identificar procesos para simplificar a través de la automatización o procesos que necesitan cambiar para evitar personalizaciones costosas. Para crear procesos optimizados para Salesforce, considere: - **Defina procesos minuciosamente**. Es más probable que los procesos con fines poco claros o definiciones ambiguas se malinterpreten en tiempo de diseño. Esto llevará a diseños defectuosos basados en supuestos, lo que dará como resultado automatizaciones incorrectas o ineficientes. Asegúrese de que los procesos de negocio que desea automatizar cumplen los siguientes estándares: - Con ámbito a una única función específica (consulte [Unidades funcionales](/docs/architect/es-mx/well-architected/guide/composable#unidades-funcionales)) - Tiene resultados claramente definidos y mensurables (consulte [Valor de negocio](/docs/architect/es-mx/well-architected/guide/automated#valor-de-negocio)) - Tiene entradas y salidas claramente definidas - **Deje claros los pasos** del proceso.\* Aunque a veces puede ser tentador agregar pasos adicionales que “podrían ser útiles en el futuro”, este nunca es un buen enfoque. Cada paso de una automatización es relevante para el resultado del proceso general. Asegúrese de que cada paso del proceso tiene las siguientes características: - Realiza una tarea específica y granular (Consultar [componible](/docs/architect/es-mx/well-architected/guide/composable)) - Requerido para que el proceso genere su resultado definido (eliminar todos los pasos no esenciales) - Se puede completar utilizando un número mínimo de recursos - Hace uso de datos del sistema existentes en vez de solicitar entradas de usuario donde sea posible (Consulte [participación](/docs/architect/es-mx/well-architected/guide/engaging)) - Proporciona opciones de entrada que los usuarios pueden comprender sin necesidad de saber cómo funcionan los sistemas subyacentes (Consulte [útil](/docs/architect/es-mx/well-architected/guide/engaging#útil)) La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/automated#patrones-de-eficiencia-y-antipatrones) a continuación muestra el aspecto de la optimización adecuada (y deficiente) en una organización de Salesforce. Puede utilizarlos para validar sus diseños de automatización antes de construir, o identificar automatizaciones que necesitan optimizarse más. Para obtener más información acerca de las herramientas de automatización de procesos disponibles en Salesforce, consulte [Herramientas relevantes para automatizado](/docs/architect/es-mx/well-architected/guide/automated#herramientas-relevantes-para-automatizados). ### Lógica operativa La lógica operativa trata de la eficacia con la que se traduce un proceso desde su diseño a una implementación real. Las automatizaciones con una sólida lógica operativa siguen teniendo un buen desempeño, independientemente de los picos en los volúmenes de transacciones o el número de instancias simultáneas que se están ejecutando. Las automatizaciones lógicamente sólidas ayudan a los negocios a ampliarse con mayor facilidad para operar con niveles de demanda más altos. La construcción de una sólida lógica operativa en sus automatizaciones está directamente relacionada con la [fiabilidad](/docs/architect/es-mx/well-architected/guide/reliable) general de su sistema. Las automatizaciones que no funcionan de forma efectiva proporcionan malas experiencias de usuario y cliente, lo que lleva a pérdidas potenciales de ingresos y pérdida de Customer Trust. También tienen costos de mantenimiento más altos y pueden convertirse en cuellos de botella que retrasan los procesos relacionados, contribuyendo a problemas de desempeño del sistema en general. Para crear lógica operativa efectiva en automatizaciones, considere: - **Asegúrese de que todos los que crean automatizaciones saben cómo hacerlo**. Se pueden realizar malas elecciones de diseño con cualquier tipo de herramienta de automatización. El código no es menos proclive a errores o malas opciones de implementación que las herramientas basadas en clics. El uso de Id. de referencia codificados, por ejemplo, es un antipatrón que aparece en Flujo y código. Las herramientas basadas en clics no deben verse como una licencia para permitir a cualquiera y a todos publicar una automatización en producción. Cada miembro del equipo que crea una automatización necesita saber cómo crearla de la forma correcta. Consulte los [estándares de diseño](/docs/architect/es-mx/well-architected/guide/intentional#estándares-de-diseño) y [legibilidad](/docs/architect/es-mx/well-architected/guide/intentional#legibilidad) para obtener más información acerca de cómo definir y aplicar estándares efectivos en sus sistemas. - **Documente claramente todas las rutas de ejecución**. El uso aumentado de automatizaciones no solo aumenta los volúmenes de datos potenciales, sino que también aumenta los contextos de invocación no planificados. Debe comprender cómo se pueden invocar diferentes automatizaciones y garantizar que los controles de transacciones apropiados (consulte Tratamiento de datos) aparecen en todas las automatizaciones que tienen múltiples puntos de entrada. Por ejemplo, los flujos de pantalla no se ejecutarán con cargas de datos masivas, pero Apex desencadena y desencadena (e inicia automáticamente) flujos probablemente sí. Documentar claramente rutas de ejecución planificadas y potenciales para automatizaciones es un aspecto clave para comprender qué condiciones lógicas tendrá que acomodar durante la implementación. - **“Bulkificar” todas las operaciones de datos (incluyendo SOQL)**. Cada operación de datos (insertar, actualizar, etc.) debe realizarse en recopilaciones. Siempre. Sin excepciones. Esto es lo que se entiende por operaciones “masivas”. Aunque la plataforma puede admitir operaciones de datos de singleton, nunca debe permitir que se implementen patrones de singleton. - **Utilice SOSL para operaciones de búsqueda**. Existe una idea errónea de que las operaciones de datos no se pueden realizar en registros devueltos a través de SOSL. Es cierto que DML no se puede invocar directamente en resultados de SOSL, pero el código puede analizar resultados de SOSL y crear una recopilación a la que se puede hacer referencia en métodos de clase DML o Database. Las diferencias clave entre SOSL y SOQL son los tipos de devolución para cada uno y cómo responden a búsquedas generalizadas o comodín. SOSL puede funcionar con varios tipos de sObject (por lo que el tipo de devolución es diferente) y puede gestionar búsquedas de comodines y cadenas generalizadas con mejor desempeño que SOQL. - **Trate SOQL como una operación de datos**. No utilice SOQL para buscar registros: utilícelo para refinar sus operaciones de datos. Las operaciones de SOQL y datos pueden tener un impacto muy similar en el desempeño de la [base de datos relacional subyacente](/docs/architect/es-mx/fundamentals/guide/platform-multitenant-architecture#la-capa-de-datos-de-plataforma). SOQL puede incluso pasar [un indicador DML explícito](https://developer.salesforce.com/docs/atlas.en-us.238.0.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_select_for_update.htm?q=for%20update) que bloqueará filas de base de datos en previsión de operaciones de datos. Para crear automatizaciones ampliables, asegúrese de tratar SOQL con diligencia debida similar: no lo utilice sin criterios de selección muy específicos y bien formados, no permita referencias de campos extraños y requiera una coincidencia de tipos de datos cuidadosa entre campos y entradas de filtro en lógica de declaración de `WHERE`. Su código también debe tener controles apropiados para garantizar que una consulta nunca se ejecutará en contextos no masivos o con criterios de filtro nulos o en blanco. - **Mantenga las operaciones síncronas estrictamente centradas en el trabajo que ayuda a un usuario en tiempo real**. Durante su [optimización de procesos](/docs/architect/es-mx/well-architected/guide/automated#diseño-de-procesos), identifique lógica relevante para lo que los usuarios necesitan hacer en tiempo real o casi en tiempo real y lo que se puede aplazar en una transacción asíncrona (asincrónica). Consulte [Tratamiento de datos](/docs/architect/es-mx/well-architected/guide/automated#gestión-de-datos) para obtener más consideraciones sobre el diseño de operaciones de sincronización/asíncronas. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/automated#patrones-de-eficiencia-y-antipatrones) a continuación muestra el aspecto de la lógica operativa adecuada (y deficiente) en la automatización de Salesforce. Puede utilizarlos para validar sus diseños de automatización antes de construir, o identificar automatizaciones que necesitan optimizarse más. Para obtener más información acerca de las herramientas disponibles en Salesforce que pueden ayudarle a planificar la escala, consulte [Herramientas relevantes para automatizadas](/docs/architect/es-mx/well-architected/guide/automated#herramientas-relevantes-para-automatizados). ### KPIs Los KPI de automatización miden la repercusión de una automatización a lo largo del tiempo. Sin ellos, no tendrá forma de saber si una automatización está agregando realmente valor de negocio o creando complejidad no intencionada para sus usuarios. Cada automatización que cree debe estar vinculada a un conjunto claro y mensurable de indicadores clave de desempeño. Los buenos KPI se definen por un valor mensurable junto con un periodo de tiempo asociado. Algunos ejemplos incluyen: - \[Número X] horas de trabajo guardadas al mes - Los fallos de procesamiento desde el ingreso manual de datos se redujeron en \[Y%] por semana Una vez que tenga indicadores clave de desempeño claros y mensurables, también debe comprender si una automatización en Salesforce generará datos relevantes para la creación de reportes sobre esos indicadores clave de desempeño y cómo hacerlo. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/automated#patrones-de-eficiencia-y-antipatrones) a continuación muestra el aspecto de los indicadores clave de desempeño apropiados (y deficientes) cuando se trata de automatizaciones de Salesforce. Puede utilizarlos para validar sus KPI existentes o identificar dónde necesita identificar mejor los KPI antes de crear. Para obtener más información acerca de las herramientas disponibles en Salesforce para obtener ayuda con los indicadores clave de desempeño, consulte [Herramientas relevantes para automatizados](/docs/architect/es-mx/well-architected/guide/automated#herramientas-relevantes-para-automatizados). ### Patrones de eficiencia y antipatrones La siguiente tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su corrección. ✨ Descubra más patrones para la eficiencia en el [Explorador de patrones](/docs/architect/es-mx/well-architected-tools/guide/easy-efficiency) y antipatrones.

	Patrones	Antipatrones
Diseño de procesos	En su organización: - Cada flujo sirve a un único propósito específico - Cada paso realiza una tarea específica y granular - Los flujos están organizados en una estructura jerárquica que consta de un flujo principal y subflujos de soporte - Todas las entradas de usuario tienen un propósito claro dentro del flujo - Solo se solicita a los usuarios proporcionar datos cuando no se pueden utilizar datos del sistema existentes	En su organización: - Los flujos sirven para múltiples propósitos y requieren entradas adicionales para proporcionar contexto - Los flujos requieren entradas cuyos datos no se utilizan - Los grupos de pasos relacionados contienen funciones que se solapan con grupos de pasos en otros flujos - Los flujos solicitan entradas de usuario cuando se pueden utilizar datos almacenados en su lugar
Diseño de procesos	En Apex: - Cada clase sirve a un único propósito específico - Cada método realiza una tarea específica y granular - Todas las variables de entrada tienen un propósito claro dentro de la clase - La ejecución de código requiere un número mínimo de recursos	En Apex: - Las clases sirven para múltiples propósitos - Los métodos realizan múltiples tareas o los métodos realizan tareas que no se alinean con el propósito declarado de la clase de la que forman parte - Las variables de entrada no se utilizan actualmente en métodos - Métodos para recuperar datos innecesariamente desde la base de datos o desde sistemas externos
Lógica operativa	En flujo: - Ninguna variable hace referencia a valores codificados (para tipos de registro, usuarios, etc.) - Todos los flujos y procesos iniciados automáticamente utilizan elementos de decisión y/o pausa para evaluar criterios de entrada y evitar bucles infinitos o ejecuciones contra grandes volúmenes de datos - Los flujos (incluyendo procesos) transfieren lógica a Apex en contextos de gran volumen de datos - Los subflujos se utilizan para las secciones de un proceso que se necesitan reutilizar en todo el negocio	En flujo: - Las variables tienen valores codificados - Los flujos (incluyendo procesos) deben desactivarse manualmente antes de cargas de datos masivas - Los flujos (incluyendo procesos) desencadenan avisos de "excepción no gestionada" - Incluso flujos sencillos causan regularmente errores relacionados con límites reguladores - Partes de un flujo se repiten entre flujos en vez de utilizar subflujos
	En Apex: - Ninguna variable hace referencia a valores codificados (para tipos de registro, usuarios, etc.) - Todos los criterios comodín aparecen en SOSL - SOQL está envuelto en `try-catch` - No aparece ningún SOQL en un bucle - Las declaraciones SOQL son selectivas, incluyendo: -- sin uso de comparaciones de `ME GUSTA` o comparaciones de texto parcial -- los operadores de comparación utilizan lógica positiva (es decir, `INCLUDES`, `IN`) como lógica principal o única -- el uso de `= NULL`, `!= NULL` es raro y/o siempre sigue un operador de comparación positivo -- no aparecen declaraciones `LIMIT 1` -- sin uso de la palabra clave `TODAS LAS FILAS`	En Apex: - Las variables tienen valores codificados - SOSL rara vez o no se utiliza de forma coherente para criterios de selección de comodines - SOQL no está envuelto en `try-catch` - SOQL aparece dentro de bucles - Las declaraciones SOQL no son selectivas, incluyendo: -- Aparecen criterios de filtro `ME GUSTA` y comodín -- las comparaciones que utilizan criterios `NO`, `NO EN` se utilizan como el operador de comparación principal o único -- `= NULL`, `!= Los` criterios se utilizan como el operador de comparación principal o único -- Aparecen instrucciones `LIMIT 1` -- Se utiliza la palabra clave `TODAS LAS FILAS`
	En sus estándares de diseño y documentación: - Las rutas de ejecución planificadas y potenciales para automatizaciones se describen claramente - Los casos de uso para operaciones síncronas y asíncronas en automatizaciones se describen claramente como parte de estándares de diseño	En sus estándares de diseño y documentación: - La invocación de automatización no está documentada - Los casos de uso para operaciones síncronas y asíncronas no se solucionan
KPIs	En su documentación: - Los resultados para cada automatización son mensurables y con plazos definidos - Las partes interesadas responsables se enumeran para cada KPI	En su documentación: - Los KPI no existen para automatizaciones o tienen plazos poco claros para mediciones - Los KPI existen sin partes interesadas responsables
KPIs	En reportes y tableros: - Todas las mediciones relacionadas con los KPI están incluidas en al menos un reporte o tablero	En reportes y tableros: - Los reportes de KPI no existen o faltan mediciones relacionadas con algunos KPI

## Integridad de datos La integridad de los datos se basa en lo bien que un sistema mantiene datos precisos y completos. Salesforce Platform mantiene una sólida [lógica de procesamiento](/docs/architect/es-mx/fundamentals/guide/architecture-basics#manipulación-de-base-de-datos) diseñada para proteger la integridad de los datos almacenados en la base de datos relacional de una organización individual. Uno de los fundamentos de la creación de automatizaciones saludables es comprender los comportamientos de integridad de datos integrados de Salesforce y asegurarse de que todos sus diseños de automatización se alinean con (y reconocen) estos comportamientos. Los mayores antipatrones en el diseño de automatización surgen de no reconocer los potentes servicios de [integridad de datos](/docs/architect/es-mx/fundamentals/guide/architecture-basics#manipulación-de-base-de-datos) ya proporcionados por Salesforce y no utilizar [la funcionalidad estándar](/docs/architect/es-mx/well-architected/guide/intentional#estándar-frente-a-funciones-personalizadas) que aprovecha estos servicios. Para diseñar automatizaciones que protegen y mantienen la integridad de los datos, debe estar familiarizado con el orden fundamental de comportamientos de operación de Salesforce. Ampliar correctamente la integridad de los datos en sus automatizaciones personalizadas significa que su sistema puede: - operar sobre volúmenes de datos masivos y grandes sin intervención manual, - aplicar políticas de seguridad de usuario cuando sea necesario y cambiar al contexto del sistema cuando sea necesario, - encontrará errores en tiempo de ejecución y seguirá rutas de recuperación o fallo predecibles. Puede construir una mejor integridad de datos en sus automatizaciones de Salesforce a través de un tratamiento de datos y un tratamiento de errores adecuados. ### Gestión de datos El primer paso para diseñar para un tratamiento de datos adecuado en Salesforce es comprender cómo gestiona la plataforma de múltiples arrendatarios [transacciones](/docs/architect/es-mx/fundamentals/guide/architecture-basics#transacciones). Esto incluye comprender el [orden de ejecución](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm) integrado que Salesforce Platform utiliza para garantizar la integridad de los datos durante las operaciones de datos a nivel de registro. Para obtener más información sobre las repercusiones de este comportamiento, consulte [Manipulación de base](/docs/architect/es-mx/fundamentals/guide/architecture-basics#manipulación-de-base-de-datos) de datos en Fundamentos de Salesforce Architecture. La gestión deficiente de los datos en sus automatizaciones puede ser uno de los antipatrones más difíciles de identificar y remediar completamente. La naturaleza recurrente y solapada del orden de ejecución de la plataforma puede dificultar la tarea de ver dónde se originan los problemas. La sección específica de código o flujo que arroja un error fatal o supera los límites reguladores podría no ser la causa raíz de un problema de gestión de datos subyacente. El _conocimiento de transacciones_ es clave para crear automatizaciones que tienen un desempeño fiable y a escala con Salesforce. Esto significa asegurarse de que cada paso de una automatización está diseñado con el Knowledge de dónde se encuentra en relación con el [orden de ejecución](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm) controlado por la plataforma, puede llevar a cabo su función correctamente y pasa la información al siguiente paso correctamente. Independientemente de la herramienta de automatización que esté utilizando, el conocimiento de transacciones adecuado sigue patrones similares y requiere consideraciones comunes: - Supongamos que se solicitará a cada automatización que se ejecute en grandes volúmenes de datos sin previo aviso, en un momento dado. Las automatizaciones deben tener rutas para permitir la ejecución por lotes o masiva (consulte [Escalabilidad](/docs/architect/es-mx/well-architected/guide/reliable#escalabilidad)). - No mezcle operaciones de datos de contexto de usuario y sistema en la misma transacción. - Reserve operaciones de datos de sincronización para [_antes de_ contextos](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm) y utilice operaciones asíncronas para todas las acciones _después_ de contextos. - Utilice [mensajería y notificaciones](/docs/architect/es-mx/well-architected/guide/engaging#notificaciones-y-mensajes) para evitar crear experiencias en aplicación que requerirían que un usuario esperara datos basándose en los resultados de una operación asíncrona. Más allá del conocimiento de transacciones, existe una segunda dimensión en el tratamiento de datos: saber cuándo llevar a cabo lógica en diferentes [contextos de ejecución](/docs/architect/es-mx/fundamentals/guide/architecture-basics#contexto-de-ejecución). Las razones comunes para dividir las automatizaciones en diferentes contextos de ejecución incluyen: - **Operaciones de datos complejas y/o de gran volumen** - [Las operaciones masivas](/docs/architect/es-mx/well-architected/guide/automated#gestión-de-datos) no garantizan que una automatización gestione grandes volúmenes de datos correctamente. Si el volumen de operaciones de datos dentro de una automatización supera los límites por transacción, deberá realizar operaciones de datos utilizando funciones específicas de grandes volúmenes de datos (como Apex por lotes o la [API masiva 2.0](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_intro.htm)). Estos tienen límites de transacciones distintos, adaptados a grandes volúmenes de datos. - Las operaciones de datos que necesitan atravesar jerarquías de relaciones complejas o realizar nuevos cálculos complejos (sin incluir campos de fórmula) entre registros pueden superar fácilmente los límites por transacción cuando se realizan de forma masiva. Considere cuán “ruidosa” es una actualización en un registro, en términos de las operaciones de datos relacionadas o SOQL necesarias para completar acciones posteriores en el sistema. - Los tipos de sObjects implicados en toda la cadena de una automatización pueden requerir que divida operaciones de datos en transacciones separadas para evitar errores de “[DML mixto](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dml_non_mix_sobjects.htm)”. - **Lógica que debe ejecutarse en contexto de usuario o sistema** - Salesforce Platform aplica la [colaboración y visibilidad](/docs/architect/es-mx/well-architected/guide/secure#colaboración-y-visibilidad) en contexto de usuario. Si necesita realizar operaciones que superan los niveles de permisos de los usuarios de su automatización, deberá asegurarse de que esas operaciones se ejecutan en contexto del sistema. - Diferentes herramientas se ejecutarán o no en diferentes contextos: - Apex se ejecutará en contexto del sistema de forma predeterminada. Puede controlar si y cómo los comportamientos Apex aplican reglas de colaboración a nivel de usuario utilizando [palabras clave colaboración](https://developer.salesforce.com/docs/atlas.en-us.238.0.apexcode.meta/apexcode/apex_classes_keywords_sharing.htm?q=run%20as%20user) en una definición de clase Apex. - El flujo no tiene un comportamiento predeterminado único. Un flujo se ejecutará en contexto de usuario o sistema [basándose en cómo se inicia](https://help.salesforce.com/s/articleView?id=sf.flow_distribute_context.htm&type=5) el flujo. Tiene la opción de aplicar la colaboración en contexto del sistema. - Los procesos (es decir, las automatizaciones creadas con Process Builder) se ejecutan en contexto del sistema sin compartir consideraciones. (Nota: Recomendamos crear automatizaciones de código bajo con Flow. - **Lógica que necesita ejecutarse de forma asíncrona** - Operaciones del sistema externo: Las llamadas síncronas o las acciones que acceden a datos externos no están incluidas en ningún comportamiento de reversión de plataforma. Para aprovechar estos comportamientos, debe colocar acciones que implican sistemas externos en transacciones separadas (utilizando métodos [Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_async_overview.htm) asíncronos, [rutas asíncronas](https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_flow_builder_asynchronous_path.htm&type=5&release=234) o [acciones invocables](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_forcecom_flow_invocable_action_callout.htm)). - Eventos y mensajería: Para controlar el flujo de eventos o mensajes relacionados con operaciones de datos (y aprovechar los comportamientos de reversión de plataforma), coloque todas las acciones relacionadas con la mensajería o los eventos [_después_ de contextos](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm), utilizando métodos Apex asíncronos. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/automated#patrones-y-antipatrones-de-integridad-de-datos) a continuación muestra el aspecto adecuado (y deficiente) de la gestión de datos en automatizaciones de Salesforce. Puede utilizarlos para validar sus diseños de automatización antes de construir, o identificar automatizaciones que necesitan refactorizarse para mejorar el tratamiento de datos. Para obtener más información acerca de las herramientas disponibles en Salesforce para el tratamiento de datos en la automatización, consulte [Herramientas relevantes para automatizado](/docs/architect/es-mx/well-architected/guide/automated#herramientas-relevantes-para-automatizados). ### Tratamiento de errores La gestión de errores es crítica para la integridad de los datos. La gestión de errores sólida también ayuda a su sistema a ampliar y envejecer con más [resiliencia](/docs/architect/es-mx/well-architected/guide/resilient). La gestión incorrecta de errores en automatizaciones puede llevar a: - Incoherencias de registro y otros problemas de integridad de datos - Envío de notificaciones imprecisas a usuarios y otros sistemas - Perder tiempo y recursos en procesamiento manual o repetido - Falta general de [Confianza](/docs/architect/es-mx/well-architected/guide/trusted-overview) en un sistema La gestión de errores en automatizaciones requiere proporcionar a cualquier proceso en ejecución la capacidad de analizar un error para obtener información, acceder a lógica acerca de cuáles deben ser los siguientes pasos basándose en información de error y luego seguir la ruta correcta. Estas funciones no necesitan crearse una y otra vez en cada automatización (eso es un [antipatrón de optimización](/docs/architect/es-mx/well-architected/guide/automated#diseño-de-procesos)). En su lugar, cada automatización en el sistema debe tener la capacidad de conectar con los [componentes](/docs/architect/es-mx/well-architected/guide/composable#acoplamiento-suelto) de gestión de errores relevantes. Para construir controles de gestión de errores apropiados en sus automatizaciones, formule estas preguntas: - ¿Qué es un error “fatal”? - ¿Qué es un error “recuperable”? - Para automatizaciones desencadenadas por acciones de usuario, ¿cómo puede la automatización captar y notificar al usuario errores antes de intentar confirmar cambios? Una vez haya decidido cómo gestionar estos errores, puede empezar a crear una gestión de errores efectiva en sus automatizaciones. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/automated#patrones-y-antipatrones-de-integridad-de-datos) a continuación muestra el aspecto adecuado (y deficiente) de la gestión de errores en una automatización de Salesforce. Puede utilizarlos para validar sus diseños de automatización antes de construir, o identificar automatizaciones que necesitan refactorizarse para mejorar la gestión de errores. Para obtener más información acerca de las herramientas disponibles en Salesforce para la gestión de errores, consulte [Herramientas relevantes para automatizado](/docs/architect/es-mx/well-architected/guide/automated#herramientas-relevantes-para-automatizados). ### Patrones y antipatrones de integridad de datos La siguiente tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su corrección. ✨ Descubra más patrones para la integridad de los datos en el [Explorador de patrones](/docs/architect/es-mx/well-architected-tools/guide/easy-data-integrity) y antipatrones.

	Patrones	Antipatrones
Tratamiento de datos	En su diccionario de datos: - Existen datos a nivel de campo y lógica de prioridad para todos los orígenes de datos y objetos de lago de datos - La asignación de campos desde el objeto de lago de datos al objeto de modelo de datos existe	En su diccionario de datos: - Los datos a nivel de campo y la lógica de priorización para orígenes de datos y objetos de lago de datos no están incluidos - La asignación de campos desde objetos de lago de datos a objetos de modelo de datos no está incluida
	En su Apex: - Todas las declaraciones DML síncronas o métodos de clase de base de datos se llevan a cabo antes de desencadenar contextos de ejecución - Las invocaciones Apex asíncronas utilizan colocables en cola para 'encadenar' DML complejos entre transacciones - Apex por lotes se utiliza exclusivamente para grandes volúmenes de datos - Apex `@future` no se utiliza o se utiliza con moderación, para llamadas o DML de objetos del sistema	En su Apex: - Las declaraciones DML aparecen regularmente en código que se invocará después de contextos de desencadenador - Apex asíncrono rara vez se utiliza - Las funciones Apex asíncronas se utilizan de forma arbitraria, incluyendo: -- Métodos futuros y Apex colocable en cola se utilizan de forma incoherente o indistinta -- Las operaciones de base de datos no tienen lógica clara y coherente para pasar la ejecución a Apex por lotes cuando sea necesario
	En flujo: - Todos los flujos iniciados en contexto de usuario abstraen todas las transacciones de contexto del sistema en subflujos, que se colocan coherentemente después de un elemento Pausa, para crear una nueva transacción - Secuencias complejas de operaciones de datos relacionadas se crean con Orchestrator (en vez de invocar múltiples subflujos dentro de un flujo monolítico) - Todos los flujos desencadenados por registros tienen valores de orden de desencadenamiento rellenados - Los flujos que implican llamadas del sistema externo o procesos de larga ejecución utilizan rutas asíncronas	En flujo: - Los flujos grandes y monolíticos intentan coordinar secuencias complejas de operaciones de datos relacionadas (con o sin subflujos) - Los flujos desencadenados por registro no utilizan atributos de orden de desencadenador en absoluto o no utilizan valores de orden de desencadenador de forma coherente - Las rutas asíncronas no se utilizan de forma coherente o en absoluto
	En su organización: - Reglas de reconciliación de Resolución de identidad siguen la lógica de prioridad en su diccionario de datos	En su organización: - Las reglas de reconciliación de Resolución de identidad no siguen la lógica de prioridad en el diccionario de datos
Tratamiento de errores	En Apex: - El código encierra todos los DML, SOQL, llamadas y otros pasos de proceso críticos en bloques de `captura de intentos` - Se utilizan excepciones personalizadas para crear lógica y mensajería de error avanzada - En contextos asíncronos y masivos, se utilizan métodos de clase de base de datos en vez de DML - Los métodos de clase de base de datos pueden utilizarse exclusivamente para todas las operaciones de datos (en vez de DML)	En Apex: - DML, SOQL, llamadas u otros pasos de proceso críticos no están incluidos de forma coherente en bloques de `captura de intentos` - Las declaraciones `System.debug` aparecen en código de producción (y no se comentan) - No se utilizan métodos de clase de base de datos - Las operaciones de datos se realizan exclusivamente con DML
	En Componentes web Lightning (LWC): - JavaScript encierra todas las operaciones de datos y pasos de procesos críticos en bloques `si ()` / `si ()` - Todas las funciones `@wire` utilizan propiedades de `datos` y `errores` proporcionadas por la API - Todas las declaraciones `si (error)` / `si (error)` contienen lógica para procesar errores y proporcionar mensajes informativos	En LWC: - JavaScript no utiliza coherentemente `si ()` / `si ()` bloques con operaciones de datos o pasos de procesos críticos - Las funciones `@wire` no utilizan propiedades de `datos` y `errores` proporcionadas por la API (o no las utilizan de forma coherente) - Si se utiliza en absoluto, `si (error)` / `si (error)` declaraciones no contienen realmente lógica para procesar errores y proporcionar mensajes de error útiles
	En Aura: - JavaScript encierra todas las operaciones de datos y pasos de procesos críticos en bloques `de intento` - Dentro de los bloques de `captura de intentos`, el `Error` de JavaScript nativo se utiliza en declaraciones throw (sin uso de `$A.error()`) - Toda la lógica de error recuperable aparece en declaraciones `de caché` y proporciona mensajes de usuario claros	En Aura: - JavaScript no encierra de forma coherente operaciones de datos y pasos de procesos críticos en bloques `de intento` - Los componentes utilizan `$A.error()` - La lógica de error recuperable no aparece de forma coherente en declaraciones de `caché`, y los mensajes de error a usuarios no son claros
	En flujo: - Los flujos de pantalla utilizan de forma coherente conectores de fallos para mostrar errores a usuarios - Los mensajes de error personalizados están configurados para errores que aparecerán en pantalla - Los flujos con operaciones de datos, llamadas y otra lógica de procesamiento crítica tienen rutas de fallo para todas las acciones clave	En flujo: - Los flujos no utilizan rutas de fallo de forma coherente o en absoluto - Los mensajes de error personalizados no se utilizan, de modo que los usuarios ven el mensaje predeterminado "Se produjo un fallo no gestionado en este flujo"

## Valor de negocio El concepto de valor de negocio, en el contexto de la automatización, trata sobre cuán bien crean los procesos un impacto positivo y mensurable para las partes interesadas de negocio. Idealmente, la automatización de procesos permite a los usuarios emplear menos tiempo en tareas repetitivas de bajo valor. También ayuda a potenciar la integridad de los datos eliminando actividades de procesamiento manual que podrían introducir errores. Al igual que [Process Design](/docs/architect/es-mx/well-architected/guide/automated#diseño-de-procesos), la identificación y entrega de automatizaciones que dirigirán el valor de negocio real requiere trabajo más allá del descubrimiento básico y el análisis de negocio. A veces, puede parecer que la mejor forma de entregar valor al negocio es simplemente automatizar cada proceso solicitado por un usuario de negocio, ya sea en el orden en que aparecen en su retraso (o cola de tickets) o basándose en factores políticos en su organización. Esto puede llevar a dos problemas relacionados: la creación de automatizaciones en un orden subóptimo y la creación de automatizaciones incorrectas por completo. El primer problema, la mala priorización, evita que los procesos de alto valor se implementen cuando deberían, lo que podría ralentizar el crecimiento. El segundo problema, la creación de automatizaciones incorrectas, no solo retrasa la entrega de automatizaciones de alto valor, sino que también lleva a tiempo mal empleado, costos innecesarios y mayor frustración entre los equipos de entrega. Puede entregar un mayor valor de negocio centrándose en los KPI y la priorización. ## Herramientas relevantes para automatizados

Herramienta	Descripción	Eficiencia	Integridad de datos	Valor de negocio
Lotes Apex	Registros por lotes juntos y procesarlos en partes gestionables	X	X
Métodos futuros Apex	Ejecutar métodos Apex de forma asíncrona en segundo plano	X	X
Pex Queueing	Agregar trabajos Apex a una cola y monitorearlos	X	X
Apex Scheduler	Ejecutar clases Apex asíncronamente en horas especificadas	X	X
Aprobaciones	Especificar los pasos requeridos para aprobar registros	X	X
Apex asíncrono	Ejecutar código Apex asíncronamente	X	X
Acciones automatizadas	Realizar actualizaciones de campo, envíos de email y otras acciones en segundo plano	X	X
Einstein Next Best Action	Mostrar las recomendaciones correctas a las personas correctas en el momento correcto	X		X
Alerta de email	Crear y enviar emails automatizados	X		X
Acciones de distribución	Especificar acciones automatizadas a realizar para distribuciones de casos	X	X
Actualización de campo	Actualizar valores de campo basándose en automatización	X	X
Flow Builder	Crear automatizaciones con una interfaz de apuntar y hacer clic	X		X
Extensiones de flujo	Acceder a variables almacenadas como entradas de componente en flujos	X
Biblioteca de plantillas de flujo	Utilizar plantillas para diseñar flujos específicos de la industria	X		X
Desencadenador de flujo	Automatizar procesos de negocio complejos	X
Acciones invocables	Agregar funciones Apex a flujos	X		X
Orquestador	Crear y gestionar automatizaciones de múltiples pasos	X	X
Mensaje saliente	Enviar información desde un proceso automatizado con recibos y reintentos		X
Publicar eventos de plataforma con flujo	Publicar eventos a través de automatizaciones e interacciones de usuario	X
Optimizador de consultas	Utilizar selectividad e índices para mejorar el desempeño de consultas, reportes y vistas de lista	X	X
Flujo de Salesforce	Crear automatizaciones de procesos declarativos con Flow Builder	X	X
Enviar notificaciones con flujos	Enviar mensajes por SMS, WhatsApp o Facebook Messenger	X		X
Enviar notificaciones con procesos	Enviar mensajes por SMS, WhatsApp o Facebook Messenger	X		X
Modificador SOQL FOR UPDATE	Bloquear registros para evitar condiciones de carrera y problemas de seguridad de hilos		X
Estrategia Builder	Identificar recomendaciones para aflorar en páginas de registro	X		X
Subflujos	Reducir la complejidad del flujo a través de la reutilización	X
Suscribirse a eventos de plataforma con flujo	Recibir mensajes publicados a través de automatizaciones	X
Acciones de tareas	Determinar detalles de asignación proporcionados a un usuario por una automatización	X

## Recursos relevantes para automatizados

Recurso	Descripción	Eficiencia	Integridad de datos	Valor de negocio
Límites y reguladores de ejecución Apex	Obtenga información acerca de cómo el motor de tiempo de ejecución Apex aplica límites	X	X
Recursos de gestión por lotes	Crear, gestionar, programar y monitorear trabajos por lotes	X	X
Mejores prácticas para SOQL y SOSL	Mejorar el desempeño de consultas de aplicaciones con grandes volúmenes de datos		X
Plantilla de estándares de diseño	Crear estándares de diseño para su organización	X	X	X
Flujo masivo en transacciones	Diseñar flujos para operar con recopilaciones	X	X
Consideraciones sobre datos de flujos	Obtenga información acerca de flujos desencadenados por programación para datos por lotes	X	X
Depuración de flujos	Probar y solucionar problemas de flujos		X
Cómo se procesan las solicitudes	Obtenga información acerca de cómo Salesforce procesa trabajos rápidamente y minimiza fallos	X	X
Plantilla de hoja de cálculo KPI	Determinar el valor de negocio de una medición concreta	X		X
Realización de llamadas a sistemas externos desde acciones invocables	Llamar a sistemas externos desde un flujo utilizando Apex	X
Operaciones DML mixtas	Saber qué sObjects se pueden utilizar juntos para DML en la misma transacción	X	X
Orden de ejecución	Comprender el orden de eventos para inserciones, actualizaciones y alteraciones	X	X
Preguntas más frecuentes sobre Plan de consulta	Optimizar consultas que implican grandes volúmenes de datos	X	X
Consideraciones sobre flujos desencadenados por programación	Comprender los comportamientos especiales de flujos desencadenados por programación	X
Control de transacciones	Generar un punto de guardado que especifique el estado actual de la base de datos	X	X
¿Qué sucede cuando falla un flujo?	Comprender la gestión de errores en flujos	X	X
Guía de mejores prácticas de automatización de flujos de trabajo	Empezar a trabajar con la automatización de Salesforce	X	X	X
Trabajar con consultas SOQL muy grandes	Redactar consultas SOQL más eficientes		X

Este es un diagrama que muestra cómo se relacionan los temas que se pueden componer a través de tres tarjetas anidadas. La tarjeta más interna es una unidad funcional, la siguiente capa es la interoperabilidad y la capa externa es la capacidad de empaquetado.

Un sistema componible:

## Separación de preocupaciones Concepto fundamental en la ingeniería de software y la arquitectura de sistemas, la _separación de preocupaciones_ implica identificar diversas preocupaciones dentro de un sistema más grande que puede separarse en unidades modulares. El logro de una fuerte separación de preocupaciones dentro de un sistema requiere la creación de unidades significativas para la lógica y funciones de aplicación en todo el sistema. Las unidades más pequeñas facilitan a los equipos de entrega y mantenimiento de aplicaciones la tarea de comprender cómo y dónde realizar cambios, con una interrupción mínima en el sistema más grande. Las unidades más pequeñas también dejan más claro cómo y dónde centrar el trabajo al abordar la [deuda técnica](/docs/architect/es-mx/well-architected/guide/intentional#deuda-técnica) y contribuyen a la [legibilidad](/docs/architect/es-mx/well-architected/guide/intentional#legibilidad) general de su sistema. Puede crear una mejor separación de preocupaciones en su organización de Salesforce orientando a la capacidad de negocio y gestionando el estado. ### Unidades funcionales Para sistemas de Salesforce, el mejor enfoque para la separación de preocupaciones aplica una perspectiva orientada al negocio para identificar y organizar unidades modulares (o funciones) dentro del sistema. Esto no se parece a una vista centrada en ingeniería, que identifica unidades basándose en su función técnica. Una perspectiva orientada al negocio en la separación de preocupaciones requiere organizar el código y las personalizaciones en su sistema basándose en el servicio que proporcionan al negocio y los usuarios de negocio. Adoptar este enfoque no significa ignorar el potencial de funciones técnicas redundantes o duplicadas en un sistema. En su lugar, significa que los servicios técnicos están claramente asignados a un principio de organización que en última instancia es transparente para el negocio. La orientación a funciones de negocio ayuda a garantizar que las transferencias entre equipos de análisis de negocio y descubrimiento a equipos de entrega sean lo más sencillas posible. Si los generadores de aplicaciones no tienen idea de dónde se asignan sus unidades de trabajo en su arquitectura componible, tiene un panorama de aplicaciones desordenado, no componible. Las asignaciones poco claras entre el estado final requerido por el negocio y las unidades modulares en una organización también aumentan las posibilidades de que los equipos de desarrollo o proveedores construyan funciones redundantes en el sistema. Considere lo siguiente para orientar las unidades funcionales a la capacidad de negocio: - **Comience con trabajos por hacer**. Céntrese en los trabajos por hacer (JTBD) de los usuarios y el negocio en sí. Con Tony Ulwick a la vanguardia, el enfoque de JTBD se centra en comprender el “trabajo”, o propósito verdadero, que las personas están intentando lograr utilizando un producto o servicio. Es un nivel de abstracción superior a las tareas relacionadas con funciones de los usuarios o los pasos individuales en un proceso de negocio. Por ejemplo, tareas como comprobaciones duplicadas y validaciones de direcciones podrían recaer en una función de orden superior de “establecer una única vista del cliente”. Después de tener una idea clara de estas funciones de negocio de orden superior, puede comenzar a asignarles partes de su sistema. - **Oriente a funciones, no a estructuras de creación** de reportes. La jerarquía interna de sus unidades de negocio no es un proxy para funciones significativas o trabajos por hacer. La jerarquía interna de su negocio tiene un impacto material en los procesos y las estructuras del equipo (por no mencionar los presupuestos). Esas son consideraciones logísticas importantes. Pero las necesidades funcionales del negocio operan en un nivel de abstracción superior a la logística. Si está creando un módulo para servir una estructura de creación de reportes en vez de una función de orden superior, tenga en cuenta que es posible que tenga que realizar pasos adicionales para identificar cómo se relaciona ese módulo con las funciones de negocio. - **Sé iterativo**. Comience asociándose con el negocio para identificar qué función podría funcionar para un producto mínimo viable (MVP). Cuando identifique una función, comience a crear ese MVP. A medida que construye, identifique los procesos, metadatos y [eventos o mensajes](/docs/architect/es-mx/well-architected/guide/composable#mensajería-y-eventos) que son centrales para la unidad funcional que está creando. Identifique cualquier proceso, metadatos y eventos o mensajes que sean dependencias externas. A medida que se diseñan unidades más funcionales, implemente la [gestión de API](/docs/architect/es-mx/well-architected/guide/composable#gestión-de-api) y la [gestión de dependencias](/docs/architect/es-mx/well-architected/guide/composable#gestión-de-dependencias) para crear unidades que funcionan bien entre sí (en vez de crear unidades en silos). La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/composable#patrones-y-antipatrones-de-separación-de-preocupaciones) a continuación muestra el aspecto de la orientación apropiada (y deficiente) a la función de negocio en una solución de Salesforce. Puede utilizarlos para validar sus diseños antes de construir o identificar áreas de su sistema que necesitan refactorizarse. Para obtener más información acerca de las herramientas disponibles de Salesforce para ayudarle a orientarse mejor a las funciones de negocio, consulte [Herramientas relevantes para componible](/docs/architect/es-mx/well-architected/guide/composable#herramientas-relevantes-para-componible). ### Gestión de estado La gestión estatal se centra en el movimiento de información en un sistema en varios puntos en el tiempo. La gestión de estado efectiva permite a las aplicaciones gestionar flujos complejos de datos o interacciones con un mínimo de resultados no planificados o indeterminados. Gestionar el estado en una organización modular de Salesforce significa crear rutas claras para flujos de lógica dentro y entre unidades, así como rutas elegantes para comportamientos de ejecución no planificados. La gestión de estado permite formar transmisiones coherentes de lógica desde unidades de aplicación modulares de Salesforce. En la mayoría de los casos, esto requiere [interoperabilidad](/docs/architect/es-mx/well-architected/guide/composable#interoperabilidad) para estructurar el flujo de información entre unidades. Las dificultades en la gestión del estado entre unidades acopladas de forma flexible a menudo llevan al desarrollo de aplicaciones monolíticas en Salesforce. Puede ver esto en grandes “monoflujos”, que se crean en un intento de orquestar un proceso complejo dentro de un flujo singular. Otro ejemplo son las clases masivas de Apex, que orquestan procesos complejos mediante _códigos espagueti_, o una larga serie de métodos de un solo uso. Estos tipos de arquitecturas de aplicación dificultan la refactorización y la depuración y aumentan los tiempos de incorporación para nuevos miembros del equipo o proveedores. También reducen el valor de las aplicaciones entregadas al negocio, ya que las funciones no son reutilizables. Considere lo siguiente para gestionar el estado en una organización modular de Salesforce: - **Decida cuándo utilizar patrones con estado frente a sin estado**. Los patrones con estado conservan información en una ruta de ejecución, mientras que los patrones sin estado no. En un sistema poco acoplado, los patrones sin estado permiten refactorizar componentes con mayor rapidez y menos efectos secundarios. Sin embargo, los patrones sin estado no son apropiados para todos los casos de uso. Si está creando componentes para operaciones de datos, los patrones con estado pueden ayudar con la integridad y la coherencia de los datos en sus sistemas. Utilice un patrón con estado si su componente cumple cualquiera de los siguientes criterios: - La conciencia de la ubicación en una ruta de ejecución superior es esencial para el comportamiento del componente - El comportamiento del componente debe cambiar basándose en los resultados de una acción descendente (por ejemplo, debe cambiar la ejecución basándose en mensajes de reversión/error/éxito desde componentes descendentes) - El componente necesita esperar respuestas de un sistema externo o descendente para finalizar su trabajo - **Cree categorías significativas para información con estado**. _Estado_ es un término ambiguo que se puede aplicar a una amplia gama de información dentro (y más allá) de una organización de Salesforce que por sí mismo el término carece casi de sentido. Un primer paso necesario para crear patrones con estado, por lo tanto, es crear categorías _con sentido_ para las rutas de ejecución con estado más importantes (o tipos de comportamientos con estado) en su sistema. Algunas categorías a tener en cuenta: - Navegación y formularios - Operaciones de base de datos - Operaciones por lotes y masivas - Errores - **Defina estados relacionados con datos en términos de [transacciones de base](/docs/architect/es-mx/fundamentals/guide/architecture-basics#manipulación-de-base-de-datos)** de datos. Los comportamientos integrados de la plataforma circunscribirán la mayoría de las consideraciones de estado para datos en Salesforce. No intente gestionar en contra o alrededor de este comportamiento. Diseñe para y con él. Diseñe soluciones que minimicen o eliminen la lógica de transacciones distribuidas. (Consulte la [gestión de datos](/docs/architect/es-mx/well-architected/guide/automated#gestión-de-datos) para obtener más detalles). - **Identifique estados que se producen dentro (y entre) unidades funcionales**. A medida que reúne unidades funcionales en sistemas más grandes, tenga en cuenta cuándo está mezclando el comportamiento de componentes sin estado y con estado, y evite combinaciones que podrían crear bucles o brechas interminables en el procesamiento. - **Defina traspasos**. Considere qué componentes de patrones de [mensajería o eventos](/docs/architect/es-mx/well-architected/guide/composable#mensajería-y-eventos) utilizarán para transmitir datos relacionados con el estado a otra parte del sistema. Asegúrese de que está creando conciencia de transacciones y [tratamiento](/docs/architect/es-mx/well-architected/guide/automated#gestión-de-datos) en sus componentes. No incluya ninguna lógica de transacción distribuida en sus transferencias. - **Cree asignaciones entre sus diagramas de proceso y estados**. Los diagramas de proceso detallan los pasos que mueven la información por su sistema en varios puntos en el tiempo. Un diagrama de estado muestra los cambios reales en la información (el estado). Utilice la parte del pie de página de metadatos de los formularios de [Diagramas de Salesforce](/docs/architect/es-mx/reference-diagrams/guide/kit-of-parts) para capturar el estado cambiante de la información en cada paso de su proceso. Si separa diagramas de proceso y diagramas de estado, asegúrese de vincularlos. Este concepto no debe confundirse con la captura del estado actual y futuro de procesos o panoramas del sistema durante el diseño y la implementación, ya que no se trata de la información que se mueve por el sistema. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/composable#patrones-y-antipatrones-de-separación-de-preocupaciones) a continuación muestra el aspecto de la gestión de estado adecuada (y deficiente) en una solución de Salesforce. Puede utilizarlos para validar sus diseños antes de construir o identificar lugares en su sistema que necesitan refactorizarse. Para obtener más información acerca de las herramientas de Salesforce para gestionar el estado, consulte [Herramientas relevantes para Componible](/docs/architect/es-mx/well-architected/guide/composable#herramientas-relevantes-para-componible). ### Patrones y antipatrones de separación de preocupaciones La siguiente tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su corrección. ✨ Descubra más patrones para la separación de preocupaciones en el [Explorador de patrones](/docs/architect/es-mx/well-architected-tools/guide/adaptable-separation-of-concerns) y antipatrones.

	Patrones	Antipatrones
Unidades funcionales	En sus estándares de diseño: - Las convenciones de nomenclatura tratan cómo denotar una unidad funcional - Existe una lista de todas las unidades funcionales definidas actualmente (y convenciones de nomenclatura relacionadas) - Existen estándares para proponer incorporaciones o cambios de unidades funcionales	En sus estándares de diseño: - Los estándares de diseño no existen o no tratan con unidades funcionales y casos de uso
	En su documentación: - Los diagramas de panorama del sistema muestran claramente las unidades funcionales en una organización - Todos los diagramas de documentación e implementación muestran claramente la(s) unidad(es) funcional(es) para componentes - La documentación para componentes individuales incluye asignación de unidades funcionales para el componente - Todos los componentes en una unidad funcional tienen capacidad de búsqueda y son fáciles de encontrar	En su documentación: - La documentación de componentes no existe - La documentación de componentes describe la unidad funcional a la que pertenece un componente, pero es el único lugar donde aparece la definición de esa unidad funcional - No puede buscar una unidad funcional concreta y/o las búsquedas no ayudan a identificar todos los componentes dentro de una unidad funcional
	En su organización: - Es posible identificar rápidamente la alineación de unidades funcionales para un elemento concreto de metadatos (por ejemplo, un flujo, una clase Apex o una página Lightning) - Las unidades funcionales se etiquetan en términos favorables a los negocios	En su organización: - No es posible identificar la alineación de unidades funcionales para cualquier metadatos - La información de la unidad funcional es incoherente o imprecisa - La información de unidades funcionales se etiqueta en términos centrados en ingeniería que no tienen sentido para usuarios de negocio
Gestión estatal	En sus estándares de diseño: - Los casos de uso para diseños con estado frente a sin estado son claros - Existen patrones aprobados para la comunicación sin estado - Existen patrones aprobados para la comunicación con estado - Borrar categorías para estado existen	En sus estándares de diseño: - Los estándares de diseño no existen o no tratan con patrones de estado/apátridas y casos de uso
	En su documentación: - Cada componente que gestiona la comunicación con estado y/o sin estado indica qué patrón se implementó - Es posible buscar y encontrar todos los componentes que implementaron un patrón de estado/apatridia concreto - Los diagramas de procesos e interacciones proporcionan detalles acerca de categorías de estado y traspasos	En su documentación: - La documentación de componentes no existe - La documentación del componente describe el patrón stateful/stateless implementado, pero es el único lugar donde aparece la definición - No es posible buscar un patrón concreto y/o las búsquedas no ayudan a identificar todos los componentes que utilizan ese patrón
	En Apex: - Se utilizan puntos de guardado y comportamientos de reversión en todas las operaciones de datos	En Apex: - Los comportamientos de Savepoints y rollback no se utilizan
	En flujo: - Se utilizan rutas de fallo y el elemento Revertir registros	En flujo: - El elemento Revertir registros no se utiliza

## Interoperabilidad En un sistema diseñado para la interoperabilidad, los componentes pueden intercambiar información y operar juntos de forma efectiva. La interoperabilidad es una clave para hacer que un sistema modular sea componible en vez de aislado. La interoperabilidad puede ser difícil de lograr en un sistema [poco acoplado](/docs/architect/es-mx/well-architected/guide/composable#acoplamiento-suelto). Debe establecer estándares para métodos de integración coherentes que no socaven la independencia entre unidades y la [separación de preocupaciones](/docs/architect/es-mx/well-architected/guide/composable#separación-de-preocupaciones) general en todo el sistema. La interoperabilidad también afecta a la calidad de sus experiencias de usuario. Sus usuarios esperan que los datos creados en un área (como información de pedidos) sean utilizables en otra (como campañas de marketing), y sus constructores esperan que si aprenden a hacer algo (como crear un flujo o autenticarse en una API) encuentren que las técnicas familiares funcionan cuando pasen al siguiente problema. No diseñar para la interoperabilidad dará como resultado arquitecturas redundantes, datos replicados, ineficiencias de procesos y costos de desarrollo y asistencia aumentados. Puede crear interoperabilidad en sistemas modulares con mensajería y eventos, así como con gestión de API. ### Mensajería y eventos Los mensajes y eventos son dos formas en que puede activar componentes en un sistema para enviar y recibir información. En términos del contenido que pueden transportar, los eventos y los mensajes son similares. Una diferencia clave es el comportamiento del remitente. Un componente que envía un _mensaje_ normalmente envía datos a un destino específico y espera algún tipo de respuesta del destinatario. Por el contrario, un componente emite un _evento_ cuando sucede algo. No hay un destino específico ni una expectativa de una respuesta. Estas diferencias de comportamiento admiten diferentes patrones de comunicación. Los mensajes admiten patrones de comunicación con estado y los eventos admiten patrones de comunicación sin estado. (Consulte [Gestión estatal](/docs/architect/es-mx/well-architected/guide/composable#gestión-de-estado) para obtener más información acerca de esta distinción.) Es importante alinear equipos en protocolos y casos de uso para mensajería y eventos. Los estándares poco claros pueden dar como resultado una mezcla de patrones en su sistema, lo que lleva a: - Problemas de desempeño y capacidad de ampliación donde se aplican patrones erróneos a un caso de uso específico - Procesamiento incoherente que hace que el sistema parezca inestable para los usuarios finales - Tiempos de solución de problemas más largos y procesos de mantenimiento más complejos Tenga en cuenta lo siguiente cuando diseñe mensajes y eventos para crear estructuras acopladas de forma más flexible en su organización de Salesforce: - **Identifique casos de uso de sincronización y asíncrono**. Eventos permite comunicaciones acopladas de forma libre, sin estado y asíncronas en un sistema. La mensajería permite patrones de comunicación más controlados, con estado y síncronos. Al decidir cuándo utilizar mensajes o eventos, debe decidir si su comunicación debe ser síncrona (y posiblemente bloqueada) frente a asíncrona y no bloqueada. - **Defina estructuras de datos cuidadosamente**. La estructura de la información que los componentes pasan entre ellos es una parte importante para mantener un sistema acoplado de forma flexible gestionable y coherente. (Consulte [API Management](/docs/architect/es-mx/well-architected/guide/composable#gestión-de-api) para obtener más información al respecto.) Una consideración clave al diseñar un mensaje o evento es la frecuencia con la que la estructura de la información puede necesitar cambiar. Una vez definido e implementado un mensaje o estructura de evento en su sistema, puede ser difícil gestionar actualizaciones, especialmente si el evento o mensaje ya se está utilizando para enviar información a un sistema externo. - **Mensajes de tamaño** correcto. En general, es una mejor práctica mantener tamaños de mensaje pequeños. Sin embargo, también existe un acto de equilibrio entre el _tamaño_ del mensaje y el _volumen_ del mensaje. Los sistemas pueden procesar cantidades menores de datos con mayor rapidez. El acto de procesamiento incluye una cantidad de gastos generales adicionales ya que los destinatarios tienen que desempaquetar, interpretar y determinar qué hacer con la información que recibieron. Estos pasos pueden tardar una cantidad insignificante de tiempo en completarse, pero pueden crear una carga en los sistemas a escala. Evite los diseños que requieren que los componentes del sistema procesen varios mensajes pequeños de forma sucesiva para completar una pieza de trabajo. Para ajustar el tamaño de sus mensajes, piense en diseñar para el mínimo de datos que los componentes descendentes necesitarán para procesar correctamente y actuar sobre la información que se envió, sin asumir también que cada componente descendente será capaz de solicitar o procesar numerosos mensajes de seguimiento. - **Diseño para escalabilidad**. Los componentes poco acoplados pueden facilitar la ampliación de su arquitectura. La eliminación de dependencias entre componentes permite a los equipos trabajar en la mejora del desempeño o la capacidad de ampliación de cualquier componente individual con efectos mínimos en los demás. Sin embargo, los componentes poco acoplados también introducen una complejidad significativa en su arquitectura a escala (especialmente cuando se trata de [gestionar estado](/docs/architect/es-mx/well-architected/guide/composable#gestión-de-estado)). Identifique procesos que necesitan tener una lógica o dependencias más estrechamente acopladas por razones de integridad de datos o experiencia de usuario válidas y no intente introducir patrones basados en eventos/asíncronos en esos procesos. Utilice patrones basados en sincronización/mensajería y la gestión de errores apropiada en su lugar. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/composable#patrones-de-interoperabilidad-y-antipatrones) a continuación muestra el aspecto adecuado (y deficiente) de la mensajería y los eventos en una solución de Salesforce. Puede utilizarlos para validar sus diseños antes de construir o identificar lugares en su sistema que necesitan refactorizarse. Para obtener más información acerca de herramientas de mensajería y eventos de Salesforce, consulte [Herramientas relevantes para Componible](/docs/architect/es-mx/well-architected/guide/composable#herramientas-relevantes-para-componible). Para obtener más información acerca de la selección de un patrón o herramienta de eventos para un caso de uso concreto, consulte la [Guía del arquitecto sobre arquitectura dirigida por eventos con Salesforce](/docs/architect/es-mx/decision-guides/guide/event-driven#key-takeaways). ### Gestión de API La creación de una gestión de interfaz de programación de aplicaciones (API) apropiada dentro de una solución de Salesforce permite que los componentes individuales de su sistema sigan patrones de comunicación predecibles. Salesforce proporciona API integradas y seguras para utilizar para la comunicación con sistemas fuera de Salesforce. (Para obtener más información sobre las API de Salesforce Platform, consulte [Fundamentos de arquitectura](/docs/architect/es-mx/fundamentals/guide/architecture-basics#api-de-plataforma).) Una gestión de API efectiva en soluciones de Salesforce es clave para crear arquitecturas realmente componibles. Permite a los componentes de una organización de Salesforce enviar y recibir información de forma eficiente. También permite a los generadores de soluciones seguir protocolos claros sobre cómo se comunican los componentes que crean con otros componentes en el sistema, y les ayuda a identificar implementaciones deficientes de forma temprana. Además, permite a los generadores de soluciones centrarse más estrictamente en el componente concreto que están creando o refactorizando, lo que potencia la productividad y la calidad. Gestión de API a nivel de compañía es un tema separado, y se logra mejor con una herramienta de Gestión de API integral. (Para obtener más información sobre la perspectiva de MuleSoft en este tema, consulte [¿Qué es Gestión de API?](https://www.mulesoft.com/resources/api/what-is-api-management#:~:text=API%20management%20is%20the%20process,create%20are%20consumable%20and%20secure.).) Considere lo siguiente para crear funciones de gestión de API en sus soluciones de Salesforce: - **Piense en las API como patrones _predecibles_ o contratos para la comunicación**. El tipo de datos de variables de entrada o salida, los nombres de variables, los elementos de información que deben (o no deben) aparecer en un patrón concreto: estas son las claves para una gestión de API efectiva. Estas definiciones deben aparecer en sus estándares de diseño, y los equipos deben poder averiguar cómo se implementaron estas definiciones en partes concretas de su sistema a través de su documentación. Una forma de ver dificultades combinando cambios desde nuevo desarrollo en un entorno de integración es mirarlos como evidencia de dónde tiene comunicaciones de API mal implementadas (o quizás ninguna definición de API en absoluto). - **No limite su pensamiento sobre las API al código exclusivamente**. Lo que define una API en este contexto es la coherencia de las estructuras y variables de mensajes en ese mensaje. Siempre que se mantenga esa coherencia, se puede implementar una API en código así como en personalizaciones declarativas, como flujos iniciados automáticamente modulares (o desencadenados por eventos de plataforma) o incluso plantillas de flujo. Basa sus decisiones en qué definir en código frente a en flujos no en implementación de API sino en [capacidad de empaquetado](/docs/architect/es-mx/well-architected/guide/composable#capacidad-de-empaquetado) y [prueba](/docs/architect/es-mx/well-architected/guide/resilient#gestión-del-ciclo-de-vida-de-aplicaciones). - **Mantenga su ciclo de vida y versiones sencillos**. Como todas las partes del desarrollo de aplicaciones, las API tienen un ciclo de vida: definir, crear, probar, implementar y mantener (incluyendo la retirada). Las API de Salesforce Platform lanzan varias versiones en un año natural, debido al ciclo de lanzamiento rápido de la plataforma. (Puede leer más sobre este comportamiento en [Fundamentos de arquitectura](/docs/architect/es-mx/fundamentals/guide/architecture-basics#api-de-plataforma) de Salesforce.) Esto significa que las API de plataforma tienen un ciclo de vida bastante complejo, ya que es necesario mantener varias versiones de una API concreta y que estén disponibles para los clientes de Salesforce. Este nivel de complejidad es apropiado para casos de uso de PaaS, pero lo más probable es que sea una complejidad innecesaria para sus arquitecturas de soluciones en plataforma (consulte: [Antipatrones de reaptitud](/docs/architect/es-mx/well-architected/guide/intentional#patrones-de-legibilidad-y-antipatrones)). Céntrese en definir un propósito claro para una API (por ejemplo, tratamiento de errores) y defina claramente la línea base. Procure tener solo una versión de cada API. - **Haga que sus API sean detectables, accesibles y gestionables**. [Documente sus API](/docs/architect/es-mx/well-architected/guide/intentional#estándares-de-diseño) de modo que los consumidores potenciales puedan encontrar API disponibles que se conecten a ellas fácilmente. Las API deben funcionar sin problemas como parte de un panorama de [capacidades](/docs/architect/es-mx/well-architected/guide/composable#unidades-funcionales). - **Sé iterativo**. Céntrese en definir e implementar solo una API interna a la vez. De ese modo, puede centrarse en iterar la definición de API rápidamente, encontrar el formulario correcto para su _única_ versión compatible y establecer mejores prácticas desde la experiencia de implementación. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/composable#patrones-de-interoperabilidad-y-antipatrones) a continuación muestra el aspecto de la gestión de API adecuada (y deficiente) en una solución de Salesforce. Puede utilizarlos para validar sus diseños antes de construir o identificar áreas de su sistema que necesitan refactorizarse. Para obtener más información acerca de las herramientas disponibles en Salesforce para ayudarle a crear más interoperabilidad, consulte [Herramientas relevantes para componible](/docs/architect/es-mx/well-architected/guide/composable#herramientas-relevantes-para-componible). ### Patrones de interoperabilidad y antipatrones La siguiente tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su corrección. ✨ Descubra más patrones de interoperabilidad en el [Explorador de patrones](/docs/architect/es-mx/well-architected-tools/guide/adaptable-interoperability) y antipatrones.

	Patrones	Antipatrones
Mensajería y eventos	En sus estándares de diseño: - Existen estándares claros para cuándo utilizar patrones síncronos (mensajería) y patrones asíncronos (tarde) - Existen estándares claros para estructuras de eventos y mensajes	En sus estándares de diseño: - Los estándares de diseño no existen, o carecen de estándares claros para patrones de sincronización frente a asíncronos y estándares claros para estructuras de mensajes o eventos
	En su organización: - Los eventos de plataforma utilizados para la mensajería interna del sistema están claramente etiquetados - Las herramientas de Salesforce Flow hacen referencia a servicios de mensajería o eventos de todo el sistema - Mensajería coherente y patrones de eventos aparecen en flujos y código	En su organización: - Los eventos de plataforma utilizados para la mensajería interna del sistema no están claramente etiquetados o no existen - Diferentes estrategias para patrones de mensajería y eventos aparecen entre flujos y códigos
	En Apex o LWC: - Las definiciones de eventos personalizados tienen un ámbito limitado (no se definen eventos o mensajes de todo el sistema en código) - Los servicios de mensajería o eventos de todo el sistema en Apex están anotados de formas que los hacen disponibles en herramientas de Salesforce Flow	En Apex o LWC: - Las estructuras de mensajes y/o eventos de todo el sistema se definen en Apex o JavaScript - Las estructuras de eventos o mensajes de todo el sistema definidas en Apex no están disponibles en herramientas como flujo
Gestión de API	En sus estándares de diseño: - Existen protocolos claros para la comunicación entre componentes (es decir, API) - Los protocolos/API se describen en grupos lógicos que los constructores pueden buscar y encontrar - Los protocolos/API definen tipos de datos de variables, nombres de variables, lo que se requiere u opcional y proporcionan una descripción clara de cuándo utilizar	En sus estándares de diseño: - Los estándares de diseño no existen o no definen API y casos de uso
	En su documentación: - La documentación de cada componente enumera claramente qué protocolo de API/comunicación se implementó - Es posible buscar una API o protocolo concreto e identificar componentes donde se implementa	En su documentación: - La documentación de componentes no existe - La documentación del componente describe la API implementada dentro de un componente, pero es el único lugar donde aparece la definición de API - No es posible buscar una API o protocolo concreto y/o las búsquedas no ayudan a identificar componentes donde se ha implementado una API o protocolo
	En su organización: - Los formatos de mensajes de API y las variables para la comunicación interna se definen con tipos de metadatos personalizados - Los formatos de mensajes de API y las variables para la comunicación interna se definen con eventos de plataforma - El código y las personalizaciones declarativas hacen referencia al tipo de metadatos personalizados apropiado (o evento de plataforma) para enviar o recibir información	En su organización: - La comunicación entre componentes del sistema (código y personalizaciones declarativas) es ad hoc - Las API se definen exclusivamente para la comunicación entre Salesforce y sistemas externos

## Capacidad de empaquetado La creación de capacidad de empaquetado en una organización de Salesforce significa que las funciones en la organización provienen de unidades que se pueden desarrollar e implementar de forma independiente y fiable, como paquetes. Idealmente, estas unidades se definen como un tipo de paquete de [segunda generación](https://developer.salesforce.com/docs/atlas.en-us.218.0.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_plan_pkg_types.htm) (ya sea un paquete desbloqueado o gestionado para ISV). Nota: Como las soluciones bien diseñadas utilizan estos tipos de paquetes exclusivamente, los paquetes gestionados de primera generación no se tratan aquí. Una cosa es definir [separaciones de preocupaciones](/docs/architect/es-mx/well-architected/guide/composable#separación-de-preocupaciones) y crear unidades funcionales en una organización de Salesforce. Otra cosa es desenredar y gestionar dependencias con la claridad suficiente para versionar correctamente esas unidades como artefactos de paquetes. Alcanzar ese nivel de estabilidad y aislamiento de metadatos requiere un nivel significativo de madurez de DevOps (y arquitectónica). También acelera el tiempo de desarrollo, mejora las experiencias del generador de aplicaciones y aporta previsibilidad y control a las versiones y la gestión de versiones. No todas las organizaciones podrán dar cobertura a la infraestructura necesaria para definir, mantener y desarrollar paquetes efectivos. Sin embargo, el objetivo final para casi todas las organizaciones de Salesforce debe ser alcanzar la capacidad de empaquetado. Puede crear capacidad de empaquetado en sus soluciones de Salesforce centrándose en el acoplamiento suelto y la gestión de dependencias. ### Acoplamiento suelto En un sistema con acoplamiento suelto, las piezas individuales no están fuertemente atadas entre sí. Muchas de las ventajas de un sistema componible se derivan del acoplamiento suelto. En sistemas empaquetables, lograr un acoplamiento suelto entre paquetes (e instalar organizaciones) le permitirá tener paquetes bien definidos y ciclos de desarrollo más productivos para equipos que trabajan con paquetes. En Salesforce Platform, puede crear paquetes [ajustados a una organización](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_org_dependent.htm) concreta. Esta función es útil para definir unidades funcionales y experimentar con la correcta [separación de preocupaciones](/docs/architect/es-mx/well-architected/guide/composable#separación-de-preocupaciones) en su organización, a medida que avanza en la madurez del empaquetado. Sin embargo, si elige este enfoque, se dará cuenta de algunos de los beneficios de los metadatos que se pueden empaquetar realmente, incluyendo el desarrollo dirigido por el origen, la capacidad de utilizar versiones y la estabilidad de artefactos. En su lugar, es probable que siga experimentando los inconvenientes de un sistema estrechamente acoplado, incluyendo: - Puntos únicos de fallo que causan interrupciones y problemas de desempeño - Implementaciones lentas e impredecibles - Ciclos de depuración y solución de problemas complejos y difíciles - Problemas de [escala](/docs/architect/es-mx/well-architected/guide/reliable#escalabilidad) y [desempeño](/docs/architect/es-mx/well-architected/guide/reliable#desempeño) El objetivo final para cualquier sistema de Salesforce empaquetable son paquetes acoplados de forma flexible. Tenga en cuenta lo siguiente cuando vea la separación de sus metadatos de Salesforce en paquetes efectivos: - **Qué personalizaciones son los datos frente a los metadatos**. Cuando se trata de la empaquetabilidad, Salesforce Platform trata los datos y los metadatos de forma muy diferente. Es importante comprender qué funciones de su organización son [metadatos o datos](/docs/architect/es-mx/fundamentals/guide/architecture-basics#metadatos-frente-a-datos). No puede incluir datos en ninguna unidad empaquetada. Cuando decida dónde comenzar a abstraer funciones en una unidad empaquetada, sus equipos tendrán que decidir si las personalizaciones almacenadas como datos deben excluirse del paquete por completo o refactorizarse en una implementación basada en metadatos. - **Cómo afectará el empaquetado a los equipos**. Una realidad logística del empaquetado de Salesforce es que gran parte del trabajo de producción y lanzamiento de una versión de paquete requiere habilidades con las tecnologías Salesforce CLI y/o CI/CD. Esto significa que las personalizaciones de código bajo y programáticas por igual requerirán tiempo y atención de alguien capaz de trabajar con tecnología de DevOps relacionada con paquetes. Dependiendo de cómo gestione su equipo la entrega de funciones, la adopción de paquetes puede suponer ralentizaciones o bloqueos significativos para diferentes equipos en una organización. Tendrá que identificar si los equipos podrán gestionar la entrega de funciones a través del empaquetado y realizar un plan para solucionar cualquier déficit de habilidades o plantilla. Las soluciones podrían incluir la adopción de programación emparejada o la implementación de trabajos de CI/CD para entornos de desarrollo. - **Cómo cambiará el empaquetado las estrategias medioambientales**. En un ciclo de vida de desarrollo dirigido por paquetes, el trabajo temprano debe realizarse en [organizaciones borrador](https://developer.salesforce.com/docs/atlas.en-us.238.0.sfdx_setup.meta/sfdx_setup/sfdx_setup_next_steps.htm?q=scratch%20org). Estos entornos de desarrollo temporales dirigidos por origen permiten ciclos más rápidos e iterativos. También admiten controles de acceso a entornos más granulares para sus equipos de desarrollo y un mayor aislamiento de la producción. Cuantas más dependencias tengan sus paquetes en metadatos no empaquetados o datos que solo existen en un entorno sandbox o de producción, menos posibilidades tendrán los equipos de utilizar organizaciones borrador. Puede [activar el seguimiento de origen en entornos sandbox](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_setup_enable_source_tracking_sandboxes.htm) para permitir patrones de desarrollo dirigidos por origen en entornos de organizaciones que no son borrador, pero sus equipos de desarrollo no se beneficiarán de la velocidad y la velocidad iterativa de las organizaciones borrador. - **Cómo se relacionan las versiones de paquetes con las versiones**. Planifique con qué frecuencia y en qué etapa del desarrollo debe producirse la versión del paquete. Las solicitudes de versión de paquetes están limitadas (por organización) de forma escalonada durante 24 horas. Como mejor práctica general, solo versione un paquete cuando esté seguro de que ninguno de los contenidos del paquete necesita cambiar. Idealmente, aprovisionará versiones de paquetes después de que se completen los procesos de garantía de calidad. No permita que los equipos de desarrollo utilicen el éxito o el fallo de las solicitudes de creación de paquetes como “pruebas” de lo bien que definieron los límites de los paquetes. Existen formas de hacerlo sin intentar versionar un artefacto de paquete. - **Lo que el estado final ideal debe admitir**. La estrategia de empaquetado ideal permite versiones controladas y estables de Salesforce que se pueden desarrollar y entregar rápidamente. La definición de demasiados paquetes en su organización puede generar nuevos tipos de complejidades y cuellos de botella para los equipos de desarrollo. Una organización demasiado modularizada también puede hacer que las versiones sean lentas y difíciles. Comience con la creación y el lanzamiento de algunas versiones de un único paquete con sentido. Derive paquetes de seguimiento de forma incremental. Deje de introducir paquetes cuando tenga una cadencia de versión que sirva bien a su negocio. Refactorice paquetes con el tiempo, si las necesidades de negocio cambian o la calidad de la versión disminuye. El estado final del paquete ideal es subjetivo. Independientemente de cómo decida definir sus paquetes, solo versionará con éxito un paquete acoplado de forma flexible a través de una [gestión de dependencias](/docs/architect/es-mx/well-architected/guide/composable#gestión-de-dependencias) efectiva. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/composable#patrones-de-empaquetabilidad-y-antipatrones) a continuación muestra el aspecto del acoplamiento suelto adecuado (y deficiente) para el empaquetado de Salesforce. Puede utilizarlos para validar sus diseños antes de construir o identificar áreas de su sistema que necesitan refactorizarse. Para obtener más información acerca de herramientas de Salesforce para ayudarle a crear más capacidad de empaquetado, consulte [Herramientas relevantes para Componible](/docs/architect/es-mx/well-architected/guide/composable#herramientas-relevantes-para-componible). ### Gestión de dependencias En el contexto de una solución de Salesforce, la gestión de dependencias significa identificar y estructurar las relaciones entre los metadatos en sus paquetes y los metadatos en las organizaciones en las que se instalarán esos paquetes. La gestión de dependencias es una parte clave del desarrollo de artefactos de paquetes estables. Las dependencias pueden estar en desacuerdo con los esfuerzos para crear unidades funcionales perfectamente separadas y [acopladas](/docs/architect/es-mx/well-architected/guide/composable#acoplamiento-suelto). En un estado de ingeniería ideal, un sistema acoplado libremente no tiene dependencias entre unidades. Sin embargo, en el mundo real, la eliminación de todas las dependencias no es práctica. A menudo, el equilibrio entre hacer que los sistemas sean [legibles](/docs/architect/es-mx/well-architected/guide/intentional#legibilidad) y utilizar [unidades funcionales](/docs/architect/es-mx/well-architected/guide/composable#unidades-funcionales) pensadas para las empresas requiere una compensación en términos de aislamiento perfecto entre las unidades de un sistema. De forma más pragmática, los servicios principales proporcionados por la [funcionalidad estándar](/docs/architect/es-mx/well-architected/guide/intentional#estándar-frente-a-funciones-personalizadas) de Salesforce Platform crean dependencias positivas netas clave para cualquier solución de Salesforce. Muchas ventajas de escalabilidad, desempeño y seguridad integradas provienen de la profundidad de su integración en la plataforma. Cuando diseñe soluciones de Salesforce empaquetables, es importante recordar que las dependencias del paquete no son inherentemente malas. La mala gestión de dependencias _es_ mala. Una gestión de dependencias efectiva con el empaquetado de Salesforce significa que los equipos de desarrollo y mantenimiento pueden: - Incorporación a nuevos proyectos más rápido y con acceso de entorno limitado - Desarrollar y probar cambios rápidamente - Comprender cómo se deben entregar funciones complejas en compromisos específicos más pequeños - Controle las cadencias de versiones y reduzca los plazos de mantenimiento/corte de versiones del sistema - Revertir cambios adversos de forma predecible en cualquier entorno Las técnicas para la gestión de dependencias con Salesforce son bastante sencillas: - Utilice [mensajería y eventos](/docs/architect/es-mx/well-architected/guide/composable#mensajería-y-eventos) para gestionar transferencias elegantes de información con estado o sin estado entre componentes. - Utilice tipos de metadatos personalizados para proporcionar información de tiempo de ejecución dinámica y para admitir patrones de inyección de dependencias. - Haga que los desarrolladores Apex utilicen [clases abstractas o virtuales](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_extending.htm). Al final, deberá decidir los patrones de diseño permitidos en su organización en el desarrollo declarativo y programático. Las consideraciones más importantes (arquitectónicamente) son definir dónde desea agregar más complejidad de ingeniería para tener menos dependencias y dónde necesita tolerar más dependencias para simplificar los flujos de trabajo del generador de aplicaciones. A medida que construye estrategias de gestión de dependencias en sus paquetes, considere los dos principios de organización principales para unidades de paquete: horizontal y vertical. - **Límites horizontales**. En paradigmas horizontales, las funciones que podrían necesitar más de un paquete se abstraen en una capa horizontal. Las capas horizontales se convierten entonces en el origen de funciones comunes y se accede a ellas a través de una dependencia declarada. Minimizar las funciones redundantes entre paquetes se favorece sobre minimizar las dependencias. - **Límites verticales**. Los paradigmas verticales maximizan el aislamiento y el acoplamiento suelto entre partes del sistema. Las funciones compartidas están limitadas y es posible que aparezca trabajo similar entre unidades. Las dependencias están estrictamente limitadas, con el fin de maximizar el aislamiento entre unidades de paquete. Tenga en cuenta que esto no es una decisión. Puede mezclar paradigmas verticales y horizontales según sea necesario. A menudo, la forma más rápida de empezar con un paquete es crear capas de servicio horizontales. A medida que crece la escala y la complejidad de la adopción de su paquete, la abstracción de más unidades verticales ayudará a simplificar procesos de configuración de entornos complejos o la incorporación de desarrolladores. Un sistema con dos unidades funcionales (A y B), por ejemplo, puede estructurarse con dependencias de paquetes dispuestas en paradigmas híbridos verticales, horizontales y verticales-horizontales.

Este es un diagrama que muestra dos paquetes, A y B, creados para no tener dependencias compartidas (porción vertical), creados para tener muchos servicios comunes (horizontal) y una mezcla de cada uno (híbrido).

Independientemente del paradigma de organización de paquetes que elija, hay algunos absolutos a tener en cuenta: - **No duplique metadatos entre paquetes**. Los metadatos necesarios para más de un paquete deben abstraerse en uno o más paquetes declarados como dependencias. - **Aproveche las dependencias integradas de los metadatos de Salesforce Platform**. Para los generadores de aplicaciones, los servicios integrados que ofrece Salesforce Platform proporcionan una gran cantidad de funciones que se pueden configurar rápidamente. Muchos de estos servicios tienen dependencias integradas que dificultan la abstracción en unidades funcionales de bajo nivel. Para un tipo de metadatos concreto, debe comprender dónde recae en el [espectro de dependencias](https://developer.salesforce.com/blogs/2018/06/lets-talk-deployment-and-reasons-why-they-succeed-or-fail) integradas y utilizar este entendimiento para [definir sus cadenas](https://developer.salesforce.com/blogs/2018/06/working-with-modular-development-and-unlocked-packages-part-2) de dependencia de paquetes. No inicie la adopción de paquetes intentando forzar el acoplamiento suelto en un elemento de funcionalidad de plataforma estándar con muchas dependencias integradas. Agregará complejidad (no valor) a medida que alcance funciones de orden superior. También es otra forma de caer en [antipatrones](/docs/architect/es-mx/well-architected/guide/intentional#patrones-de-mantenimiento-y-antipatrones) [estándar frente a personalizados](/docs/architect/es-mx/well-architected/guide/intentional#estándar-frente-a-funciones-personalizadas). Empaquete metadatos desde abajo (menos dependencias) hacia arriba e itérelos a lo largo del tiempo. - **Cuidado con sus cadenas de dependencias**. Evite crear cadenas de dependencia de paquetes que requerirán que los desarrolladores dividan sus cambios en muchos paquetes diferentes en cualquier momento. - **Piense en lo que tiene sentido para el control de origen**. Existen dos formas básicas de gestionar sus paquetes en el control de origen. El primero es un _monorrepo_ único con paquetes aislados en carpetas. El segundo es múltiples representantes con paquetes aislados en sus propios representantes. Existen complejidades en la gestión de cada tipo de estrategia de origen, a largo plazo. En términos de incorporación de desarrollador, los límites verticales son más eficientes en múltiples paradigmas de repositorio. Los límites horizontales son más comprensibles en un monodepósito. De nuevo, puede mezclar y combinar estrategias a medida que madura su arquitectura. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/composable#patrones-de-empaquetabilidad-y-antipatrones) a continuación muestra el aspecto de la gestión de dependencias adecuada (y deficiente) con paquetes de Salesforce. Puede utilizarlos para validar sus diseños antes de construir o identificar áreas de su sistema que necesitan refactorizarse. Para obtener más información acerca de herramientas de Salesforce para la gestión de dependencias, consulte [Herramientas relevantes para Componible](/docs/architect/es-mx/well-architected/guide/composable#herramientas-relevantes-para-componible). ### Patrones de empaquetabilidad y antipatrones La siguiente tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su corrección. ✨ Descubra más patrones para la empaquetabilidad en el [Explorador de patrones](/docs/architect/es-mx/well-architected-tools/guide/adaptable-packageability) y antipatrones.

	Patrones	Antipatrones
Acoplamiento suelto	En sus estándares de diseño: - Las convenciones de nomenclatura tratan cómo denotar unidades de paquetes - Es posible buscar y encontrar una lista de todas las unidades de paquete definidas actualmente (y convenciones de nomenclatura relacionadas) - Existen estándares para proponer adiciones o cambios de unidades de paquete - (Opcional) Todos los casos de uso aprobados para configuraciones personalizadas están claramente enumerados (si los tiene)	En sus estándares de diseño: - Los estándares de diseño no existen o no tratan con unidades de paquetes y casos de uso
	En su organización: - Los tipos de metadatos personalizados proporcionan información dinámica en tiempo de ejecución para personalizaciones de código y declarativas - No existen configuraciones personalizadas o existen pocas configuraciones personalizadas, y ninguna está relacionada con funciones empaquetadas - No existen objetos personalizados para proporcionar información dinámica en tiempo de ejecución para personalizaciones de código o declarativas	En su organización: - Se utiliza la configuración personalizada - Los objetos personalizados existen con el fin de proporcionar información dinámica en tiempo de ejecución para personalizaciones de código o declarativas - Los tipos de metadatos personalizados no se utilizan (o no se utilizan de forma coherente) para proporcionar información dinámica en tiempo de ejecución para personalizaciones de código y declarativas
	En Apex: - Los servicios comunes y el código de placa de caldera se definen utilizando clases Apex abstractas o virtuales - Los métodos dependientes de información dinámica en tiempo de ejecución hacen referencia a tipos de metadatos personalizados apropiados	En Apex: - Los servicios comunes y el código de placa de caldera no se distinguen fácilmente de otras clases - Las referencias internas entre clases y métodos son difíciles de seguir y no son coherentes en toda la base de códigos - Los métodos no utilizan un enfoque coherente para acceder a información dinámica en tiempo de ejecución, o los métodos consultan objetos personalizados para información de comportamiento en tiempo de ejecución, o el código hace referencia a parámetros personalizados
	En entornos de desarrollo y control de origen: - los archivos package.xml solo aparecen en la etapa inicial o manifiestos de proyecto de prueba de concepto	En entornos de desarrollo y control de origen: - Los archivos package.xml se utilizan para controlar implementaciones de metadatos
	En paquetes: - Los paquetes desbloqueados dependientes de la organización solo se utilizan para experimentos de etapa temprana o prueba de concepto - No se definen paquetes no gestionados en entornos de producción o sandboxes	En paquetes: - Todos los paquetes son paquetes desbloqueados dependientes de la organización - Los paquetes no gestionados se definen en entornos de producción o sandbox
Gestión de dependencias	En sus estándares de diseño: - Existen estándares para declarar dependencias - Existen estándares para introducir o modificar dependencias	En sus estándares de diseño: - Los estándares de diseño no existen o no tratan sobre cómo declarar dependencias
	En control de origen: - Las versiones de paquetes para paquetes desbloqueados utilizan alias (`LATEST`) para declarar dependencias en manifiestos `sfdx-project.json` - Los desarrolladores pueden crear organizaciones borrador e implementar metadatos de paquetes con éxito desde el control de origen	En control de origen: - Las versiones de paquetes para paquetes desbloqueados se declaran explícitamente (sin alias `MÁS RECIENTE`) en manifiestos `sfdx-project.json` - Los desarrolladores no pueden trabajar con éxito con organizaciones borrador utilizando el control de origen
	En sus paquetes: - No se duplican metadatos entre paquetes - Para el desarrollo de paquetes, todo el trabajo de desarrollo en la etapa inicial se produce en organizaciones borrador	En sus paquetes: - Las dependencias se evitan duplicando metadatos en diferentes paquetes - El desarrollo temprano de paquetes se produce en sandboxes de desarrollador o el desarrollo temprano de paquetes no puede producirse en organizaciones borrador
	Consulte también: Acoplamiento suelto

## Herramientas relevantes para Componible

Herramienta	Descripción	Separación de preocupaciones	Interoperabilidad	Capacidad de empaquetado
Servicios web REST Apex	Exponer sus clases y métodos Apex a aplicaciones externas a través de REST		X
Servicios web Apex SOAP	Exponer sus clases y métodos Apex a aplicaciones externas a través de SOAP		X
Captura de datos	Publicar cambios en registros de Salesforce		X
Tipos de metadatos personalizados	Definir funciones reutilizables, personalizables y empaquetables			X
Decoradores	Exponer funciones o propiedades públicamente como una API	X	X
Dev Hub	Gestione organizaciones borrador, paquetes de segunda generación y funciones Einstein.	X	X	X
Eventos genéricos (heredados)*	Enviar eventos personalizados que no están vinculados a cambios de datos de Salesforce		X
Servicio de datos Lightning	Almacenar en caché y compartir datos entre componentes	X	X
Metadata API	Implementar personalizaciones entre entornos de Salesforce			X
Reporte de cobertura de metadatos	Determinar la cobertura de metadatos admitida entre varios canales			X
MuleSoft Composer	Crear automatización de procesos para datos utilizando clics en vez de código		X
Mensajes salientes	Enviar mensajes a extremos externos cuando se actualizan valores de campo		X
Eventos de plataforma	Enviar mensajes seguros y ampliables que contienen datos de eventos casi en tiempo real		X
API Pub/Sub	Suscribirse a eventos de plataforma, Captura de datos de cambios o Monitoreo de eventos en tiempo real		X
Eventos de temas distribuidos (heredados)*	Enviar y recibir notificaciones de cambios de datos que coinciden con una consulta SOQL definida por el usuario		X
Salesforce CLI	Desarrollar y crear automatización al trabajar con su organización de Salesforce			X
Diagramas de Salesforce	Crear diagramas para mostrar funciones de negocio y detalles técnicos	X
Extensiones de Salesforce para Visual Studio Code (ampliado)	Extensiones oficiales de VS Code para el desarrollo de Salesforce			X
Organizaciones borrador	Implementar metadatos y código de Salesforce en una organización desechable			X
Paquetes gestionados de segunda generación	Desarrollar y distribuir aplicaciones para AppExchange			X
API de herramientas	Crear herramientas de desarrollo personalizadas o aplicaciones para aplicaciones de Lightning Platform			X
Paquetes desbloqueados	Organizar metadatos, empaquetar una aplicación o ampliar una aplicación AppExchange			X
*Salesforce continuará admitiendo PushTopic y Eventos genéricos dentro de las funciones actuales, pero no tiene intención de realizar más inversiones en esta tecnología.

## Recursos relevantes para Componible

Recurso	Descripción	Separación de preocupaciones	Interoperabilidad	Capacidad de empaquetado
Una mirada primitiva a la integración digital	Desarrollar un lenguaje común para conceptos de conectividad		X
Aplicación de diseño dirigido por dominios con Salesforce	Oriente sus soluciones alrededor de funciones de negocio	X
Mejores prácticas para paquetes de segunda generación	Comprender patrones y prácticas de empaquetado 2GP			X
Componentes disponibles en paquetes gestionados	Comprender componentes de metadatos de paquetes gestionados			X
Plantilla de estándares de diseño	Crear estándares de diseño para su organización	X	X	X
Guía de decisiones de arquitectura dirigida por eventos	Comparar herramientas y patrones de arquitectura dirigidos por eventos		X
Antipatrones de eventos	Identificar antipatrones a evitar al utilizar eventos		X
Cómo diseñar API dirigidas por mensajes y eventos	Lea las diferencias en una guía del desarrollador de MuleSoft	X	X
Aprendizaje sobre el marco de trabajo por hacer	Explorar JTBD en Trailhead	X
Gestionar el estado global en B2C Commerce	Pasar datos fácilmente entre componentes para mantener el estado	X
Directrices de mensajería	Comunicar información relevante y crear momentos de placer		X
Tipos de mensajería	Comprender diferentes tipos de mensajería por la naturaleza de la interacción de usuario		X
Tipos de metadatos	Comprender los diferentes tipos de metadatos en su organización de Salesforce	X		X
Tipos de notificación de aplicaciones móviles	Comprender tipos de notificación para aplicaciones móviles Salesforce		X
Optimización del estado de vista	Mantener el estado en una página Visualforce	X
Experiencia de desarrollador de Salesforce (DX)	Gestionar y desarrollar aplicaciones en Lightning Platform	X	X	X
Tipos de metadatos no admitidos	Identificar componentes que no están disponibles en la API de metadatos			X

## Dinos lo que piensas Ayúdenos a mantener Salesforce Well-Architected relevante para usted; realice nuestra [encuesta](https://sfdc.co/bxNtvh) para proporcionar comentarios sobre este contenido e indicarnos qué le gustaría ver a continuación. ## Introducción Salesforce Well-Architected representa directrices y mejores prácticas de expertos en Salesforce y en todo nuestro ecosistema. Gracias a todos los que han aportado recursos y Knowledge a well-architected. Actualizamos documentos bien diseñados dos veces al año. Anunciaremos cómo contribuir a Well-Architected durante nuestro siguiente plazo de mantenimiento. Puede proporcionar comentarios sobre Well-Architected en cualquier momento [aquí](https://sfdc.co/bxNtvh). ## Dinos lo que piensas Ayúdenos a mantener Salesforce Well-Architected relevante para usted; realice nuestra [encuesta](https://sfdc.co/bxNtvh) para proporcionar comentarios sobre este contenido e indicarnos qué le gustaría ver a continuación. > Lea sobre nuestras programaciones de actualizaciones [aquí](/docs/architect/es-mx/well-architected/guide/contributors). Aviso legal: Este documento se distribuye únicamente para uso informativo; no constituye asesoramiento legal y no debe utilizarse como tal. ## Introducción Un sistema compatible está diseñado para cumplir con las directrices legales y éticas aplicables, siendo su cumplimiento mensurable y auditable. Esto se demuestra restringiendo el acceso a los datos a personas autorizadas para fines específicos, respetando las leyes relevantes y garantizando el acceso equitativo para todos los usuarios autorizados. Las medidas proactivas son esenciales para prevenir y detectar infracciones de cumplimiento. Un enfoque reactivo a las leyes y estándares puede erosionar Customer Trust, particularmente si los cambios solo se producen en respuesta a solicitudes o quejas de clientes. Dichas quejas pueden dañar la marca y la reputación de su organización y pueden provocar pérdidas de ingresos. Puede crear cumplimiento en sus soluciones de Salesforce centrándose en tres hábitos clave: adhesión legal, estándares éticos y accesibilidad. ## Adhesión legal La adhesión a mandatos legales implica seguir leyes regionales y regulaciones de la industria. Como arquitecto, una vez que el equipo legal de su organización o un auditor externo haya determinado los requisitos de cumplimiento específicos, su responsabilidad es comprender estos requisitos e identificar y marcar de forma proactiva posibles problemas de cumplimiento al principio del proceso de diseño para reducir el riesgo de multas y demandas. Puede mejorar la adhesión legal en sus soluciones de Salesforce a través de la localización y privacidad de datos. ### Privacidad de datos La privacidad de datos trata sobre cómo su solución recopila, almacena y procesa información de identificación personal (PII), junto con las leyes relevantes y la capacidad de un individuo para controlar el acceso a sus datos personales. El cumplimiento de estas leyes puede requerir actualizaciones en su [modelo de visibilidad](/docs/architect/es-mx/well-architected/guide/secure#colaboración-y-visibilidad) y colaboración, modificaciones en configuraciones de metadatos para restringir el acceso, la implementación de cifrado a nivel de campo, el monitoreo de registros y eventos, la creación de automatizaciones para exportar o eliminar datos de un cliente bajo solicitud y el desarrollo de políticas que rigen el uso de datos en automatizaciones e IA. El incumplimiento de las leyes de privacidad de datos puede llevar a multas y demandas sustanciales. Además, la exposición de datos de partes interesadas debido a controles insuficientes o una brecha de seguridad puede dar como resultado pérdida de ingresos y erosionar Customer Trust. Tenga en cuenta lo siguiente cuando trabaje para garantizar el cumplimiento de los requisitos de privacidad de datos: - **Consulte expertos reguladores**. Trabaje con su equipo legal o un auditor externo para evaluar las leyes de cumplimiento específicas de la industria aplicables a su negocio. Por ejemplo, las compañías de cuidados sanitarios deben cumplir la Ley de Responsabilidad y Portabilidad del Seguro Médico (HIPAA). - **Clasifique sus datos**. La clasificación de datos ayuda a los equipos de proyectos a comprender cuándo se pueden utilizar o no los diversos elementos de datos en su organización. También proporciona a su negocio la capacidad de [reportar](https://help.salesforce.com/s/articleView?id=sf.data_classification_report.htm&type=5) sobre el cumplimiento de la política de gestión de datos. Clasifique los datos en su organización especificando las leyes aplicables [en el nivel](https://help.salesforce.com/s/articleView?id=sf.data_classification_intro.htm&type=5) de campo para capturar quién es el propietario, el nivel de confidencialidad y si el campo está en uso actualmente. Durante el proceso de clasificación, es importante pensar en cómo se podrían utilizar todos los campos en su modelo de datos y no solo aquellos que parecen ser confidenciales a primera vista. En algunos casos, los campos que parecen intrascendentes pueden volverse confidenciales si se utilizan en el contexto incorrecto. Por ejemplo, los códigos postales en los Estados Unidos pueden ser un proxy para raza y, por lo tanto, si se utilizan en un modo predictivo, podrían agregar sesgos o causar daño de forma no intencionada. Los nombres se pueden utilizar para predecir el género, el país de origen, la raza, la religión e incluso la edad, ya que los nombres populares tienden a cambiar de generación en generación. Incluya clasificaciones de todos los campos y una descripción clara de cómo las utilizará cualquier función de IA asociada en su documentación. Utilice herramientas como [Detección de datos](https://help.salesforce.com/s/articleView?id=sf.einstein_data_detect.htm&type=5) para identificar datos confidenciales en su organización. Si los campos están clasificados como confidenciales o si sabe qué campos son confidenciales, herramientas como Selección de contenido de Einstein también identificarán campos que están [altamente correlacionados](https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.mc_pb_manage_einstein_content_selection_attributes_and_bias.htm) y, por lo tanto, pueden ser proxies para esos campos confidenciales. - **Establezca mejores prácticas para la gobernanza de datos**. Asegúrese de que toda la documentación relevante está completa, actualizada y almacenada de forma centralizada de modo que esté disponible fácilmente para todas las partes interesadas. Esto agregará una capa de protección para su organización contra la responsabilidad legal mientras mantiene Trust con sus clientes y socios. Por ejemplo, un diccionario de datos documenta las definiciones y clasificaciones a nivel de objeto y campo para todos los elementos de datos que se almacenarán en su sistema, los documentos de diseño contienen detalles acerca de cualquier automatización que creó para cumplir con las leyes y una matriz de seguridad describe a qué datos tienen acceso los usuarios. De forma crítica, esta documentación integral se convierte en la fuente autorizada para la generación aumentada de recuperación (RAG), fundamentando directamente sistemas de agentes como Agentforce en contexto operativo verificado y compatible, evitando así resultados incoherentes o alucinados. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/compliant#patrones-de-adhesión-legal-y-antipatrones) a continuación muestra el aspecto adecuado (y deficiente) de la gestión de la privacidad de los datos en una solución de Salesforce. Utilice estos para validar sus diseños antes de construir o identificar áreas de su sistema que necesitan refactorizarse. Para obtener más información acerca de las herramientas de Salesforce para la privacidad de datos, consulte [Herramientas relevantes para cumplir](/docs/architect/es-mx/well-architected/guide/compliant#herramientas-relevantes-para-cumplir). ### Localización La localización se trata de adaptar un producto para alinearse con un idioma, una cultura y una estética local específicos. Esto también incluye la adaptación a leyes específicas de la región, como leyes de residencia de datos, que pueden diferir significativamente entre países e incluso municipios. En consecuencia, es posible que sus sistemas necesiten satisfacer múltiples marcos reguladores, dependiendo de la ubicación de sus clientes y cómo su negocio presenta sus productos y servicios en el mercado. Además de las variaciones en las leyes de privacidad de datos, muchos países también están promulgando leyes de residencia de datos. Como mínimo, las leyes de residencia de datos requieren que todos los datos relacionados con los ciudadanos de un país se almacenen físicamente dentro de las fronteras de ese país. Algunas leyes van más allá, requiriendo el almacenamiento local de todos los datos (incluyendo datos sobre productos y servicios) potencialmente accesibles por los ciudadanos. En ciertos casos, las leyes requieren que los datos de ciudadanos sean mantenidos únicamente por otros ciudadanos de ese país o región. El incumplimiento podría llevar a grandes multas y demandas. Por ejemplo, las autoridades de protección de datos de la UE pueden imponer multas de hasta 20 millones de euros o el 4% de los ingresos globales, cualquiera que sea superior. En los Estados Unidos, la oficina del fiscal general de California puede solicitar sanciones significativas por violaciones intencionales y no intencionales. Considere lo siguiente para gestionar mejor los requisitos de residencia de datos y localización: - **Consulte expertos reguladores**. Trabaje con su equipo legal o un auditor externo para evaluar leyes en las regiones donde opera su negocio para determinar cuáles son aplicables. Algunos ejemplos incluyen el Reglamento general de protección de datos (RGPD) y la Ley de IA de la UE, así como la Ley de privacidad del consumidor de California (CCPA). - **Almacene datos localmente**. Asegúrese de que los datos específicos de una región permanecen en su propia organización separada. Utilice [Hyperforce](https://help.salesforce.com/s/articleView?id=000356459&type=1), el sustrato de nube pública de Salesforce para alojar su organización en una región específica. - **Evite la replicación** de datos. Almacenamiento de datos local significa que los datos se almacenan _en tiempo de_ inactividad en el país; por supuesto, los problemas de cumplimiento pueden surgir cuando los datos se transfieren fuera del país a través de interfaces estándar. Por ejemplo, la creación y el mantenimiento de registros localmente pero su replicación en un almacén de datos en otro país para la creación de reportes infringirá las leyes de residencia de datos. Si trabaja para un negocio global con requisitos de creación de reportes entre regiones, primero agregue sus datos dentro del país donde están almacenados, elimine toda la información que podría identificar a los ciudadanos asociados con él y luego replique solo la información agregada. Este enfoque puede requerir que comunique limitaciones de creación de reportes a sus partes interesadas de modo que sepan que, aunque habrá más datos granulares disponibles a nivel de país o regional, solo habrá datos de resumen disponibles a nivel global. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/compliant#patrones-de-adhesión-legal-y-antipatrones) a continuación muestra el aspecto de los procesos de localización y residencia de datos apropiados (y deficientes) en una solución de Salesforce. Utilice estos para validar sus diseños antes de construir o identificar áreas que necesitan refactorizarse. Para obtener más información acerca de las herramientas de Salesforce para la localización, consulte [Herramientas relevantes para cumplir](/docs/architect/es-mx/well-architected/guide/compliant#herramientas-relevantes-para-cumplir). ### Patrones de adhesión legal y antipatrones La siguiente tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su corrección. ✨ Descubra más patrones para la adhesión legal en el [Explorador de patrones](/docs/architect/es-mx/well-architected-tools/guide/trusted-legal-adherence) y antipatrones.

	Patrones	Antipatrones
Privacidad de datos	En su documentación: - Tiene un diccionario de datos actualizado que contiene nombres de nivel de campo, descripciones y clasificaciones - Tiene una matriz de seguridad actualizada que identifica qué usuarios tienen acceso a qué datos - Tiene documentación de diseño actualizada, incluyendo estándares y diagramas para cualquier automatización creada para tratar requisitos reguladores	En su documentación: - Un diccionario de datos no existe o no se ha mantenido actualizado - La documentación de colaboración y visibilidad no existe o no se ha mantenido actualizada - Los estándares de diseño, los diagramas y la documentación para automatizaciones que abordan requisitos reguladores no existen o no se han mantenido actualizados
Privacidad de datos	En su organización: - Todos los objetos y campos que contienen información confidencial o están sujetos a leyes de privacidad de datos tienen Categorización de cumplimiento, Propietario de datos, Nivel de confidencialidad de datos y Uso de campo configurados	En su organización: - A los objetos y campos que contienen información confidencial o están sujetos a leyes de privacidad de datos les falta configuración para Categorización de cumplimiento, Propietario de datos, Nivel de confidencialidad de datos o Uso de campo
Localización	En su documentación: - Tiene una estrategia de organización que describe dónde se almacenarán y mantendrán los datos para cumplir con todos los requisitos de residencia de datos aplicables - Tiene una estrategia de integración que describe escenarios y procesos aceptables para replicar datos a través de fronteras - Tiene una estrategia de análisis que describe el nivel de granularidad que los reportes y tableros pueden contener a nivel regional, nacional y global	En su documentación: - No tiene una estrategia de organización o su estrategia de organización no trata los requisitos de residencia y localización de datos - No tiene una estrategia de integración o su estrategia de integración no trata los requisitos de residencia y localización de datos - No tiene una estrategia de análisis o su estrategia de análisis no trata los requisitos de residencia y localización de datos

## Estándares éticos En contextos de negocio, las normas éticas son las directrices para el modo en que las compañías y los individuos se comportan desde un punto de vista moral o basado en valores. En Salesforce, [nuestros valores principales](https://trailhead.salesforce.com/content/learn/modules/salesforce-culture-and-values/explore-salesforce-culture-and-values) guían todo lo que hacemos como compañía y como empleados. También tenemos un equipo de [políticas de uso](https://www.salesforce.com/company/intentional-innovation/ethical-use-policy/) ético que ayuda a garantizar que los clientes están utilizando nuestro software de forma ética. Nuestra [Política de uso aceptable (AUP)](https://sfdc.co/AUP) y [Política de uso aceptable](http://sfdc.co/AI-Policy) de IA son una extensión de nuestros valores principales y ayuda a guiar nuestra toma de decisiones si surgen preguntas acerca del uso. Su organización puede tener un conjunto adicional de políticas que se amplían más allá del simple cumplimiento de las leyes locales. Estas políticas pueden adoptar varias formas, que van desde la adhesión a las leyes de otras regiones, la negativa a hacer negocios con ciertas organizaciones o mercados o el monitoreo de interacciones empleado-cliente para evitar la discriminación o comportamientos sesgados. Para mantener estas políticas, es posible que tenga que actualizar sus estándares de diseño o configuración del sistema como lo haría para la [adhesión legal](/docs/architect/es-mx/well-architected/guide/compliant#adhesión-legal). Para fomentar una mayor adhesión a estándares éticos en sus soluciones de Salesforce, alinee con las políticas de la compañía y evalúe su uso de inteligencia artificial. ### Políticas de la compañía Las políticas de la compañía son directrices que definen cómo deben operar varios aspectos del negocio (incluyendo personas, procesos y tecnología). Los clientes prefieren hacer negocios con organizaciones de su Trust. La mayoría de las políticas de la compañía están diseñadas para reflejar este principio. Customer Trust se erosionará rápidamente si sus sistemas crean experiencias de usuario que no se alinean con sus políticas declaradas. Las políticas eficaces surgen naturalmente de [una cultura ética](https://www.salesforce.com/blog/new-research-ethical-leadership-business/). Cada empleado, desde la ingeniería y el diseño hasta la ciencia de datos, el marketing y las ventas, debe recibir educación sobre su responsabilidad para el uso ético. En una cultura de este tipo, los empleados ven estructuras de incentivos claras para recompensar el comportamiento ético y consecuencias claras y coherentes para el comportamiento poco ético. Considere lo siguiente para asegurarse de que las políticas de su organización se reflejan en sus diseños: - **Tenga en cuenta las consecuencias no deseadas**. Como arquitecto, es su responsabilidad anticipar las posibles repercusiones de sus soluciones y cómo se utilizarán. No caiga en la trampa de solo considerar o probar rutas felices. En su lugar, aplique su experiencia en la prueba de casos extremos y la evaluación de compensaciones para considerar minuciosamente las implicaciones éticas de sus soluciones. Piense en todas las personas que se verán afectadas por el producto, especialmente aquellas que están subrepresentadas, marginadas o vulnerables. Evalúe la multitud de formas en que alguien o algo podría interactuar con su solución y crear consecuencias no deseadas. Utilice el [Kit de herramientas](http://sfdc.co/BuildwithIntention) Construir con intención para diseñar teniendo en cuenta la inclusión. - **Incruste la ética en la política de uso aceptable de su compañía**. Trabaje con su equipo legal o un tercero para incluir la ética en su política de uso aceptable para garantizar que el uso de sus soluciones se alinea con los valores de su compañía. Su documentación debe incluir información acerca de cuáles de los valores y políticas de su organización son compatibles con sus soluciones, ya sea desarrolladas con herramientas de código bajo o pro-código. Publique su política de uso aceptable para mostrar su compromiso con Trust con sus empleados y clientes. - **Utilice lenguaje inclusivo**. Comprenda las diferentes formas en que las personas experimentan su solución y [refine el lenguaje](https://www.salesforce.com/news/stories/salesforce-updates-technical-language-in-ongoing-effort-to-address-implicit-bias/) en su interfaz de usuario, código y documentación para reflejar con mayor precisión la inclusión. Empiece identificando y eliminando el lenguaje exclusivo primero y luego comprometiéndose a comprender los tipos de hábitos o prácticas que pueden llevar a la exclusión. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/compliant#patrones-y-antipatrones-de-estándares-éticos) a continuación muestra el aspecto adecuado (y deficiente) de la adhesión a las políticas de la compañía en una solución de Salesforce. Utilice estos para validar sus diseños antes de construir o identificar áreas en su sistema que necesitan refactorizarse. Para obtener más información acerca de herramientas de Salesforce para alinear diseños con políticas de la compañía, consulte [Herramientas relevantes para cumplir](/docs/architect/es-mx/well-architected/guide/compliant#herramientas-relevantes-para-cumplir). ### Inteligencia artificial La inteligencia artificial utiliza sistemas computacionales para realizar tareas que normalmente requieren inteligencia humana, como el razonamiento, la percepción y la toma de decisiones. Las funciones de IA de la plataforma Salesforce abarcan tecnologías predictivas, generativas y de agentes, ofreciendo un conjunto integral de herramientas para mejorar las experiencias de los clientes y las operaciones de negocio: - La **IA predictiva** analiza datos históricos y pronostica resultados futuros, como tendencias de ventas o abandono de clientes. Einstein AI entrega estas perspectivas analizando patrones en sus datos para proporcionar recomendaciones y predecir resultados de negocio. - La **IA generativa se** centra en la creación de nuevo contenido aprovechando modelos de idiomas de gran tamaño. Einstein GPT es un componente principal que funciona con sus datos de CRM para generar contenido personalizado como emails, respuestas de chat y comunicaciones de clientes. - La **IA genética** lleva la IA un paso más allá permitiendo a los agentes razonar y actuar de forma autónoma para alcanzar un objetivo específico. Agentforce es la plataforma para la creación de estos agentes inteligentes, que pueden automatizar procesos de negocio complejos como la resolución de casos de clientes o la optimización de campañas de marketing. Estos agentes pueden interactuar con datos en tiempo real a través de Data 360 y aprovechar los flujos de trabajo y las API existentes. Todas estas funciones de IA están protegidas por Einstein Trust Layer, que garantiza un uso ético. La mayoría de los algoritmos principales de IA de Einstein no son configurables, pero para algunas funciones, los clientes pueden ajustar los modelos utilizando sus propios datos como se indica en la documentación. Además, puede fundamentar modelos de IA en su propio CRM, artículos de la base de Knowledge y otros documentos a través de Fundamentación aumentada de recuperación (RAG) para que los resultados sean aún más precisos para su organización, clientes y casos de uso. Sin embargo, si sus datos subyacentes están sesgados o sesgados, sus resultados también podrían estar sesgados e imprecisos. Un ejemplo de sesgo es no incluir miembros de una determinada raza, género u origen étnico en su lista de contactos aunque su base de clientes sea diversa e incluya miembros de ese grupo. Consulte el [módulo Creación responsable](https://trailhead.salesforce.com/en/content/learn/modules/responsible-creation-of-artificial-intelligence) de IA de Salesforce Trailhead, [Comprender Trailhead](https://trailhead.salesforce.com/content/learn/modules/trusted-agentic-ai), [Modelo de madurez](https://www.salesforceairesearch.com/static/ethics/EthicalAIMaturityModel.pdf) ética de IA, [Principios IA de confianza](https://www.salesforceairesearch.com/trusted-ai), [Directrices de IA](https://www.salesforce.com/news/stories/generative-ai-guidelines/) generativa responsable y [Directrices de IA](https://www.salesforce.com/news/stories/responsible-agentic-ai-guidelines/) agente responsable para obtener más información. No tener en cuenta las leyes aplicables y los estándares éticos propios de su compañía puede llevar a sesgos dentro de su IA, dando como resultado demandas, pérdida de ingresos, problemas de Customer Trust y daños a la imagen pública de su compañía. Esto es lo que debe tener en cuenta para el uso responsable y ético de la IA: - **Examine sus conjuntos de datos y documentos**. Asegúrese de que sus conjuntos de datos son representativos de todas las personas a las que afectará su función de IA. Esto puede requerir investigación de usuario para comprender quiénes son y confirmar que sus datos los representan con precisión a todos para mitigar cualquier sesgo potencial. También es importante revisar los datos de CRM, los artículos Knowledge y cualquier otra documentación en la que fundamente sus modelos para asegurarse de que están actualizados, son precisos y completos. Fundamentar sus modelos en cargas de datos no es útil y puede dar como resultado alucinaciones si esos datos son antiguos, contradictorios o incompletos. - **[Mantén un humano al timón](https://www.salesforce.com/news/stories/human-at-the-helm/)**. No desea que los seres humanos intervengan en cada interacción de IA individual, sino que potencie a sus empleados para centrarse en los elementos de alto juicio que más necesitan su atención. Pruebe sus sistemas de IA hasta que esté seguro de que pueden asumir más responsabilidad y monitorear los resultados para garantizar que continúan funcionando de forma precisa y efectiva. Asegúrese de que sus sistemas o agentes de IA reciben instrucciones de distribuirse a un humano para casos de uso de alto riesgo y cuando el nivel de confianza de la IA es bajo. - **Priorice la seguridad de los resultados y las salidas de su modelo**. Realice [evaluaciones](https://www.salesforce.com/news/stories/developing-ethical-ai/) de sesgo, capacidad de explicación y solidez, así como [equipo ético rojo](https://www.salesforce.com/blog/red-teaming-ai/). Dé prioridad a la protección de la privacidad a través de respuestas y acciones de agentes para cualquier información de identificación personal (PII) presente en los datos utilizados para la capacitación y cree barandillas para evitar daños adicionales. Si detecta resultados dañinos al realizar pruebas, agregue instrucciones a sus solicitudes del sistema y vuelva a realizar pruebas. También es posible que necesite mejorar la calidad o representatividad de los datos que está utilizando para Recuperación de generación aumentada (RAG). - **Prepárese para regulaciones**. Además de las preocupaciones éticas con la IA, muchos gobiernos han aprobado o están aprobando legislación para regular el uso de la IA por organizaciones que operan dentro de sus jurisdicciones. Esta legislación puede incluir el requisito de publicar tarjetas modelo que describen cómo se creó y funciona una solución de IA. Antes de implementar una solución basada en inteligencia artificial, tenga en cuenta qué tipo de funciones relacionadas con la IA son o no aceptables en las regiones donde se utilizarán sus sistemas y realice los ajustes necesarios en su estrategia. Es posible que tenga que desactivar ciertas funciones en algunas regiones para cumplir con las leyes locales; si es así, asegúrese de que sus sistemas pueden seguir funcionando sin esas funciones. Muchas jurisdicciones también requieren transparencia cuando los clientes o usuarios finales interactúan con sistemas de IA. - **Monitoree los modelos de IA de su organización**. Los usuarios afectados deben saber cuándo se utilizó una IA y tener la oportunidad de reportar fácilmente daños y solicitar reparación. Es importante tener en cuenta que la creación de reportes por sí sola puede no ser suficiente para determinar si su función de IA está causando daño a los usuarios. Monitoree continuamente sus modelos en busca de desviación de datos, cambios en puntuajes de equidad/sesgo, precisión y solidez. Asegúrese de tener planes establecidos para [gestionar alertas de calidad](https://help.salesforce.com/s/articleView?id=sf.bi_edd_quality_alert.htm&type=5) y responder rápidamente cuando se identifiquen impactos negativos. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/compliant#patrones-y-antipatrones-de-estándares-éticos) a continuación muestra el aspecto adecuado (y deficiente) del diseño de la IA en una solución de Salesforce. Utilice estos para validar sus diseños antes de construir o identificar áreas de su sistema que necesitan refactorizarse. Para obtener más información acerca de herramientas de Salesforce para implementar políticas de IA más éticas, consulte [Herramientas relevantes para cumplir](/docs/architect/es-mx/well-architected/guide/compliant#herramientas-relevantes-para-cumplir). ### Patrones y antipatrones de estándares éticos La siguiente tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su corrección. ✨ Descubra más patrones para estándares éticos en el [Explorador de patrones](/docs/architect/es-mx/well-architected-tools/guide/trusted-ethical-standards) y antipatrones.

	Patrones	Antipatrones
Políticas de compañía	En sus estándares de diseño: - Los estándares incluyen directrices claras para áreas afectadas por políticas de la compañía	En sus estándares de diseño: - Los estándares de diseño no existen o no proporcionan directrices claras acerca de áreas sujetas a políticas de la compañía
	En su documentación: - La documentación para la configuración y personalizaciones incluye referencias a valores de compañía admitidos	En su documentación: - La documentación para la configuración y personalizaciones no hace referencia a valores o políticas de la compañía
	En su organización: - Todos los objetos y campos sujetos al cumplimiento relacionado con la política de la compañía tienen Categorización de cumplimiento, Propietario de datos, Nivel de confidencialidad de datos y Uso de campo configurados	En su organización: - Los objetos y que están sujetos al cumplimiento relacionado con la política de la compañía carecen de configuración para Categorización de cumplimiento, Propietario de datos, Nivel de confidencialidad de datos o Uso de campo
Inteligencia artificial	En sus estándares de diseño: - Las políticas y los casos de uso aprobados para aplicaciones de IA son claros y fáciles de encontrar - Asegúrese de que los datos y documentos utilizados para RAG son representativos, completos, precisos y actualizados. Busque sesgo, contenido tóxico y otro contenido dañino que podría estar en sus conjuntos de datos o documentación - Las respuestas generativas siempre identifican orígenes de datos utilizados por modelos de IA - Los conjuntos de datos que se pueden/no se pueden utilizar para la ingeniería de solicitudes se han documentado - Los bots y las respuestas de IA generativa están claramente identificados para los usuarios - Estándares para cuándo y cómo utilizar renuncias de responsabilidad para la IA generativa están claramente definidos - Existen requisitos claros sobre cómo documentar puntos de implicación humana en diseños de soluciones de IA - Existen estándares para documentar rutas de comentarios directos e indirectos en diseños de soluciones de IA - Los puntos en los que se debe identificar la IA para un usuario están claramente definidos - Mantener un humano al frente, especialmente en casos de uso regulados o de alto riesgo	En sus estándares de diseño: - Los estándares de diseño no existen o no incluyen políticas claras y casos de uso aprobados para aplicaciones de IA - Las respuestas generativas no identifican orígenes de datos utilizados por modelos de IA - Los conjuntos de datos utilizados para la ingeniería de solicitudes no están documentados - Los bots y las respuestas de IA generativa no se identifican para los usuarios - Faltan renuncias de responsabilidad respecto a respuestas generativas - No existen requisitos para documentar puntos de implicación humana en diseños de soluciones de IA - No existen estándares para documentar rutas de comentarios directos e indirectos para diseños de soluciones de IA - Los estándares de diseño no indican los puntos en los que se debe identificar la IA a los usuarios
Inteligencia artificial	En su documentación: - La documentación para la configuración y personalizaciones que implican funciones de IA contiene una descripción exhaustiva de toda la lógica de procesos y se almacena en una ubicación central accesible para equipos legales o auditores - Los modelos que crea o aporta a Salesforce están claramente documentados, incluyendo cualquier segmento de datos aplicable - Lógica de plática y pláticas de agentes están completamente documentadas - Existen procesos para monitorear los modelos de IA de su organización en busca de desviación de datos, cambios en puntuajes de equidad y sesgo, precisión y robustez - Las descripciones se mantienen para los datos de entrenamiento, evaluación y prueba utilizados para todos los procesos de IA - Las descripciones se mantienen para cualquier limpieza de datos relacionada con la IA junto con pruebas de sesgo, resultados asociados y puntuajes de desempeño/precisión (por ejemplo, puntuajes F1)	En su documentación: - La documentación para la configuración y personalizaciones que implican funciones de IA falta, está incompleta o almacenada en una ubicación inaccesible - Los modelos o sistemas de IA se implementan en su organización sin documentación de sus modelos - Los agentes se implementan en su organización sin documentación de mensajes y flujo de plática - Los procesos de monitoreo de IA no existen o no están documentados - La información sobre los datos de entrenamiento, evaluación y prueba utilizados para todos los procesos de IA no está clara o no está disponible - La información sobre la limpieza de datos relacionados con la IA, las pruebas de sesgo y los resultados no está clara o no está disponible

## Accesibilidad _La accesibilidad_ en tecnología hace referencia a la capacidad de uso de sistemas o soluciones para personas con capacidades diferentes. El diseño de sistemas que funcionen para todos los usuarios, independientemente de su capacidad, es un mandato legal en algunas ubicaciones e industrias. Más allá de los requisitos legales, la creación de sistemas accesibles ayuda su organización a fomentar y mejorar Trust con sus partes interesadas. Para aplicaciones de cara al cliente, esto puede incluso aumentar los ingresos ya que los clientes pueden optar por utilizar sus sistemas en lugar de alternativas menos accesibles. Salesforce publica [Reportes de cumplimiento](https://www.salesforce.com/company/legal/508_accessibility/) de accesibilidad (ACR), que son documentos estándar de la industria que detallan cómo cumple nuestro software con los estándares de accesibilidad. La mayoría de nuestros controles basados en la interfaz de usuario, incluyendo Componentes web Lightning y Plantillas de Experience Cloud, están diseñados para cumplir estos estándares. Aunque nuestras funciones de accesibilidad de línea base pueden ser suficientes para muchos negocios, es importante revisar nuestros ACR y notas de la versión antes de iniciar cualquier proyecto. Esto le ayudará a identificar y documentar cualquier requisito de accesibilidad adicional que se extienda más allá de nuestros estándares, dependiendo del enfoque de salida al mercado de su producto o servicio. Puede mejorar la accesibilidad de sus sistemas centrándose en dos áreas clave: la entrada de datos y la navegación. ### Entrada de datos Las actividades de entrada de datos se producen siempre que un usuario necesita ingresar información en un campo, formulario u otra parte de una interfaz de usuario. Aunque los teclados y los ratones son los métodos de entrada más comunes, algunos usuarios pueden basarse en voz en texto o dispositivos similares. Además, sus usuarios pueden comunicarse en diferentes idiomas. Las soluciones no diseñadas teniendo en cuenta la accesibilidad pueden excluir a personas con ciertas discapacidades de interactuar con ellas. Tenga en cuenta lo siguiente cuando diseñe para la accesibilidad: - **El idioma preferido** por sus usuarios. Dependiendo de dónde opere su negocio, es posible que decida establecer un idioma estándar único para sus sistemas o que desee ofrecer funciones en varios idiomas. Si muestra texto en varios idiomas, sus estándares de diseño deben incluir una lista de etiquetas de campo y otros elementos de la interfaz de usuario (como notificaciones y mensajes de error) que requieren traducción. Haga que un hablante nativo revise las traducciones para determinar su precisión y significado. Utilice [funciones de traducción](https://help.salesforce.com/s/articleView?id=sf.workbench_overview.htm&type=5) de Salesforce para traducciones de metadatos y datos en tiempo real, y pruebe minuciosamente todas las funciones multilingüe. - **Los tipos de dispositivos de entrada que se utilizarán**. Enumere cualquier herramienta que pueda utilizarse para la entrada de datos más allá de un teclado y ratón estándar en sus estándares de diseño. Incluya pruebas de accesibilidad en sus planes de prueba y asegúrese de que todas las entradas se prueban con múltiples tipos de dispositivos de entrada. - **La capacidad de uso de sus formularios**. Asegúrese de que sus formularios incluyen etiquetas visibles, proporcionan mensajes de error útiles, guían al usuario hacia la finalización, informan al usuario de su progreso y le permiten revisar, confirmar y modificar sus entradas. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/compliant#patrones-de-accesibilidad-y-antipatrones) a continuación muestra el aspecto de la entrada de datos cuando se diseña correctamente (y mal) para la accesibilidad en una solución de Salesforce. Utilice estos para validar sus diseños antes de construir o identificar áreas en su sistema que necesitan refactorizarse. Para obtener más información acerca de las herramientas de Salesforce para crear una entrada de datos más accesible, consulte [Herramientas relevantes para cumplir](/docs/architect/es-mx/well-architected/guide/compliant#herramientas-relevantes-para-cumplir). ### Navegación La navegación implica que los usuarios muevan el enfoque entre pantallas y entre campos en una pantalla. Es posible que los usuarios necesiten navegar por los diversos elementos de la interfaz de usuario en su sistema de varias formas, incluyendo a través de clics y pulsaciones de teclas, mientras dependen de su vista, oído y tacto. Asegúrese de que sus estándares de diseño incluyen una lista de dispositivos de navegación que tiene intención de admitir. Los equipos de implementación deben consultar esta lista cuando realicen pruebas para asegurarse de que se tienen en cuenta todas las posibilidades de navegación. Tenga en cuenta las siguientes preguntas (y sus respuestas) cuando diseñe la navegación accesible: - **¿Cómo navegarán los usuarios por su solución?** Enumere cualquier dispositivo que pueda utilizarse para la navegación más allá de un teclado y ratón estándar en sus estándares de diseño. - **¿Es coherente su navegación?** Establezca estándares de diseño para controles de navegación para garantizar la coherencia en todo su sistema. Las rutas de navegación deben ser similares en todo su sistema. La navegación incoherente, como un botón azul “Siguiente” en la parte inferior derecha de una pantalla y un botón verde “Siguiente” en el centro de la siguiente, podría ser una molestia leve para algunos usuarios, pero puede hacer que la aplicación no sea utilizable para personas con discapacidad. - **¿Tienen sus pruebas en cuenta la accesibilidad?** Incluya pruebas de accesibilidad en sus planes de prueba y asegúrese de que todos los flujos de navegación se prueban con múltiples tipos de dispositivos de entrada. - **¿El enfoque del teclado es visible de forma coherente?** Muestre siempre visualmente el estado actual del enfoque del teclado para ayudar a los usuarios que dependen de un teclado a navegar. - **¿Su navegación depende del color?** Evite utilizar solo el color para presentar información o solicitar una acción. Cumpla las [Directrices de accesibilidad](https://www.w3.org/TR/WCAG20/#visual-audio-contrast) de contenido web (WCAG) 2.0 para un uso adecuado del color para transmitir significado y aplicar el nivel de contraste correcto. - **¿Se revisaron sus diseños?** Realice revisiones periódicas para garantizar que su interfaz de usuario es coherente y fácil de comprender. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/compliant#patrones-de-accesibilidad-y-antipatrones) a continuación muestra el aspecto de la navegación cuando se diseña correctamente (y de forma deficiente) para la accesibilidad en una solución de Salesforce. Utilice estos para validar sus diseños antes de construir o identificar áreas de su sistema que necesitan refactorizarse. Para obtener más información acerca de las herramientas de Salesforce para crear una navegación más accesible, consulte [Herramientas relevantes para cumplir](/docs/architect/es-mx/well-architected/guide/compliant#herramientas-relevantes-para-cumplir). ### Patrones de accesibilidad y antipatrones La siguiente tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su corrección. ✨ Descubra más patrones de accesibilidad en el [Explorador de patrones](/docs/architect/es-mx/well-architected-tools/guide/trusted-accessibility) y antipatrones.

	Patrones	Antipatrones
Entrada de datos	En sus estándares de diseño: - Se enumeran todos los dispositivos que se pueden utilizar para la entrada de datos más allá de un teclado y ratón estándar - Los valores de texto y sus traducciones a todos los idiomas admitidos se enumeran	En sus estándares de diseño: - Solo se enumeran algunos, o ninguno, de los dispositivos que se pueden utilizar para la entrada de datos más allá de un teclado y ratón estándar - Los idiomas admitidos se enumeran junto con elementos de la interfaz de usuario para traducir
	En sus planes de prueba: - Los pasos de prueba incluyen el uso de múltiples tipos de dispositivos de entrada para ingresar datos - Los pasos de prueba incluyen entrada de datos en múltiples idiomas	En sus planes de prueba: - Las pruebas de accesibilidad no están incluidas o las pruebas de entrada de datos accesibles se realizan ad hoc
	En su organización: - Las traducciones para idiomas admitidos se almacenan en Sistema de traducción	En su organización: - Las traducciones se almacenan en etiquetas personalizadas
Navegación	En sus estándares de diseño: - Todos los dispositivos que se pueden utilizar para la navegación (no solo teclado y ratón estándar) están claramente enumerados - Los estándares de interfaz de usuario/UX especifican el tipo y el estilo de todos los controles de navegación - Los tipos de señales visuales aprobadas para transmitir significado o estado están claramente enumerados, y el color no es una señal principal	En sus estándares de diseño: - Los estándares de diseño no existen o no tienen en cuenta los requisitos de accesibilidad para controles de navegación - Los estándares de interfaz de usuario/UX para la navegación son incoherentes - Las pistas visuales para significado o estado se basan en color o no hay listas claras de pistas visuales para constructores
Navegación	En sus planes de prueba: - Los pasos de prueba incluyen el uso de múltiples tipos de dispositivos de entrada para navegar - Los planes de prueba incluyen el uso de pruebas de interfaz de usuario/UX para garantizar rutas de navegación coherentes	En sus planes de prueba: - Las pruebas de accesibilidad no están incluidas o las pruebas de navegación accesible se realizan ad hoc

## Herramientas relevantes para cumplir

Herramienta	Descripción	Adhesión legal	Estándares éticos	Accesibilidad
Agenteforce Analytics	Obtenga perspectivas sobre el desempeño de sus agentes		X
Centro de pruebas de Agentforce	Ejecute hasta 10 trabajos de prueba con hasta 1.000 casos de prueba por prueba, de modo que pueda crear y evaluar rápidamente múltiples escenarios.		X
Citas	Las citas le ayudan a identificar posibles imprecisiones o alucinaciones en las respuestas generadas, aumentando su confianza en el uso de herramientas de IA.		X
API de consentimiento	Realizar un seguimiento de preferencias de clientes para consentimiento	X
Transmisión de evento de consentimiento	Enviar notificaciones de cambios en la información de contacto o consentimiento	X
Objetos de Gestión de consentimiento	Gestionar preferencias de consentimiento y privacidad de clientes	X
Acceso y portabilidad de datos	Exportar datos relacionados con clientes bajo solicitud	X
Clasificación de datos	Registrar información de auditoría y cumplimiento de claves para campos de objeto	X
Reportes de Data 360	Monitorear el cumplimiento de instrucciones de agentes		X
Eliminación de datos	Eliminar datos para cumplir con las leyes	X
Preferencias de privacidad de datos	Almacenar preferencias de privacidad de datos de clientes	X	X
Traducción de datos	Traducir datos presentados a usuarios	X		X
Detección de datos	Alinear categorías y niveles de confidencialidad con datos reales	X
Explorador de Data 360	Gestionar permisos de objeto y proyecto para científicos de datos	X	X
Einstein Data Prism	Una solución de fundamentación para aplicaciones de IA generativa en Salesforce, mejorando la precisión de soluciones de IA que utilizan sus funciones de fundamentación		X
Einstein Trust Layer	Un conjunto de funciones, procesos y políticas diseñados para salvaguardar la privacidad de los datos, mejorar la precisión de la IA y promover el uso responsable de la IA en todo el ecosistema de Salesforce		X
Registros de eventos mejorados	Los registros de eventos capturan los eventos y mensajes de usuario en una sesión de agente para revisar Adhesión de instrucciones, probar y solucionar problemas de su agente.		X
Files Connect	Examinar, buscar y compartir archivos externos desde Salesforce	X
Hyperforce	Cumplir con los requisitos de almacenamiento de datos locales	X
Traducción de metadatos	Traducir idiomas a aplicaciones de localización	X		X
API de portabilidad	Compilar datos de clientes identificados en su política de portabilidad	X	X
Centro de preferencias	Recopilar preferencias de comunicación de clientes	X	X
Centro de privacidad	Satisfacer solicitudes de clientes y leyes de privacidad de datos	X	X
Restricción del procesamiento de datos	Restringir métodos de procesamiento de datos personales	X	X
Derecho al olvido	Eliminar datos de clientes individuales bajo solicitud	X
Archivos de Salesforce	Compartir y almacenar archivos de forma privada	X
Centro de seguridad	Ver parámetros de seguridad y privacidad entre múltiples organizaciones	X
Shield Platform Encryption	Cifrar datos en periodos de inactividad y tránsito	X
Traducción Workbench	Mantener valores traducidos para etiquetas de metadatos y datos	X		X

## Recursos relevantes para cumplir

Recurso	Descripción	Adhesión legal	Estándares éticos	Accesibilidad
5 principios para un diseño de IA responsable	Diseñar funciones de Inteligencia artificial (IA) de forma ética		X
Fundamentos de accesibilidad (Trailhead)	Aprenda por qué la accesibilidad es importante			X
Reportes de conformidad de accesibilidad (ACR)	Comprender cómo Salesforce cumple los estándares de accesibilidad			X
Descripción general de accesibilidad	Comprender la accesibilidad en Salesforce Lightning			X
Modelo de madurez de ética de IA	Desarrollar una hoja de ruta para poner en práctica principios éticos		X
AI Red Teaming: Pruebas para Trust	Descubra cómo los “hackers éticos” de Salesforce desarrollan la IA responsable a través del trabajo en equipo de color rojo.		X
Automatización del adversario: Diseño de un marco de trabajo ampliable para la IA de Red Teaming	Obtenga información acerca de cómo Salesforce automatiza la generación de solicitudes adversarias y la validación de respuestas, fuzzai ayuda a proteger interacciones de IA mientras reduce la exposición humana a contenido dañino.		X
Mejores prácticas para el diseño de pláticas	Seguir mejores prácticas al diseñar chatbots		X	X
Mejores prácticas para el diseño sostenible (Trailhead)	Incorporar sostenibilidad en sus diseños		X
Gestión de consentimiento	Realizar un seguimiento y cumplir con solicitudes de consentimiento y anulación de suscripción	X
Data Policies for Einstein	Controlar el uso de datos en funciones Einstein	X	X
Plantilla de estándares de diseño	Crear estándares de diseño para su organización	X	X	X
Las prácticas de piratería ética resultan exitosas en la creación de productos IA de confianza	Obtenga información acerca de cómo Salesforce emplea prácticas de equipo rojo para mejorar la seguridad de nuestros productos de IA mediante pruebas de uso malicioso, ataques de integridad intencionados, uso indebido benigno e identificación de problemas de IA responsables.		X
Liderazgo ético y negocios	Perspectivas sobre tecnología, igualdad y ética		X
Política de uso ético	Explorar la política de Salesforce sobre el uso ético de nuestros productos y servicios		X
Ética por diseño (Trailhead)	Incorporar el diseño ético en el desarrollo tecnológico		X
Explorar la cultura y los valores de Salesforce (Trailhead)	Explorar los valores principales de Salesforce		X	X
Seguir directrices de diseño móvil accesibles	Siga las mejores prácticas para que sus diseños sean accesibles		X	X
Primeros pasos con accesibilidad web (Trailhead)	Aprenda los fundamentos de cómo hacer accesibles sitios web y aplicaciones			X
Cómo Salesforce crea infraestructura de Red Teaming reproducible	Cuatro componentes que recomendamos al diseñar, implementar y ejecutar pruebas adversarias		X
Cómo ejecutar un taller de exploración de consecuencias	Considere todos los resultados posibles mientras innova		X
Implementación de la privacidad y la protección de datos	Evaluar requisitos de privacidad y protección de datos	X
Diseño inclusivo (Trailhead)	Fomentar la innovación con principios de diseño inclusivo		X	X
Plantilla de hoja de cálculo KPI	Establecer indicadores clave de desempeño (KPI) para su organización	X
Información legal	Explorar el centro de información legal de Salesforce	X
Módulo de consentimiento de cookies LWC	Controlar el acceso de cookies de usuario en sitios de Experience Cloud	X	X
Descripción general de privacidad	Obtenga información acerca de la privacidad de datos por región e industria	X
Promover agentes responsables y éticos	Aprenda cómo implementar estrategias éticas de creación de equipos rojos y pruebas y desarrollar principios y estándares de orientación para su organización.		X
Directrices de IA agente responsable			X
Creación responsable del módulo de IA Trailhead	Aprenda cómo eliminar el sesgo de sus datos y algoritmos para crear sistemas de IA éticos en su compañía.		X
Directrices de IA generativa responsables	Nos hemos basado en nuestros Principios IA de confianza con un nuevo conjunto de directrices centradas en el desarrollo y la aplicación responsables de la IA generativa.		X
Certificaciones de cumplimiento de Salesforce	Revisar certificados y certificaciones de cumplimiento de Salesforce	X
Diseño sostenible (Trailhead)	Fortalecer la relación entre las empresas y la sociedad		X
Pruebas de accesibilidad web (Trailhead)	Utilizar pruebas automatizadas y manuales para garantizar la accesibilidad			X
IA agente de confianza	Aprenda cómo Agentforce utiliza salvaguardas y principios de IA responsables para crear IA ética.		x

Seguro
Un sistema seguro protege el negocio, las partes interesadas y los datos. Las arquitecturas seguras garantizan que solo los usuarios aprobados puedan obtener acceso, restringir el acceso de usuarios a lo esencial para realizar el trabajo y proteger los datos dentro del sistema de verse comprometidos.
Seguridad organizativa	Seguridad de sesión	Seguridad de datos
Autenticación Autorización	Gestión de sesiones Acceso de dispositivo Detección y respuesta ante amenazas	Colaboración y visibilidad Uso de cifrado
Cumplimiento
Las soluciones compatibles siguen directrices legales y éticas. Las arquitecturas compatibles cumplen con las leyes y los estándares de la industria, mantienen políticas éticas y sirven a todos los usuarios de forma equitativa.
Adhesión legal	Normas éticas	Accesibilidad
Privacidad de datos Localización	Políticas de la compañía Inteligencia artificial	Entrada de datos Navegación
Fiable
Las soluciones fiables funcionan de forma eficiente y fiable, bajo una serie de condiciones. Las arquitecturas fiables están disponibles cuando y donde los usuarios esperan, tienen un desempeño coherente y se amplían con el negocio.
Disponibilidad	Desempeño	Escalabilidad
Gestión de riesgos Mitigación de fallos	Rendimiento Latencia	Modelado de datos Volumen de datos

## Introducción Diagram showing Salesforce Well-Architected core capabilities are Trusted, Easy, Adaptable

Marco de trabajo bien arquitectado de Salesforce le muestra el aspecto de la salud y dónde emplear su tiempo en la hoja de ruta y el diseño de soluciones con Salesforce Customer 360 Platform. Comparte directrices prescriptivas y ejemplos de patrones y antipatrones a buscar en su panorama, basándose en Knowledge de equipos de productos y expertos en implementación en Salesforce y nuestro ecosistema. Salesforce Well-Architected está organizado para ayudarle a crear soluciones de confianza, fáciles y adaptables. Las soluciones de **confianza** protegen a las partes interesadas.
Las soluciones **fáciles** entregan valor rápidamente.
Las soluciones **adaptables** evolucionan con el negocio.
Salesforce Well-Architected está diseñado para ayudarle a pasar por el pensamiento arquitectónico requerido para crear soluciones saludables en Customer 360 Platform. Un reto único para los arquitectos que crean soluciones con Salesforce es la flexibilidad fundamental de la plataforma. Una solución podría ampliar una solución preconstruida ofrecida por Salesforce (por ejemplo, Sales Cloud, Service Cloud, diferentes verticales de Industries Cloud). Otra solución podría ser una aplicación completamente personalizada. Lo que puede hacer con Salesforce es amplio y profundo, y las opciones de tecnología específicas que mejor se ajusten a su implementación dependerán de las necesidades de negocio. Puede ser tremendamente difícil saber qué creará la mejor oportunidad de salud a largo plazo para cada solución posible de Salesforce. Salesforce Well-Architected le proporciona perspectivas y directrices de arquitectos altamente experimentados según lo necesite. Puede utilizar las vistas y recomendaciones con opiniones para validar (o desafiar) su pensamiento y obtener perspectivas sobre áreas de consideración o tecnología que pueden ser nuevas para usted. También puede ser difícil de comprender si existen indicadores arquitectónicos comunes a todas las soluciones saludables, dada la amplia variedad entre implementaciones. En Salesforce, todo lo que hacemos como compañía y como personas se guía por nuestros valores fundamentales. Creemos que esto también se puede aplicar a la arquitectura. Es por eso que Salesforce Well-Architected está construida alrededor de un núcleo de Confianza, Fácil y Adaptable. A medida que evalúa detalles arquitectónicos complejos y ventajas, puede volver a estas funciones principales y utilizarlas como puntos de brújula para guiar su toma de decisiones. A continuación encontrará detalles sobre temas individuales para explorar en nuestro marco de trabajo de confianza, fácil y adaptable. ## Cómo se organizan los temas Utilizamos dos niveles para organizar la información en Salesforce Well-Architected. El nivel superior es lo que deben ser las soluciones bien diseñadas: Confiable, Fácil y Adaptable. El segundo nivel profundiza más en consideraciones, patrones para crear (o antipatrones para evitar) y directrices prescriptivas relacionadas con aspectos específicos de soluciones de confianza, fáciles y adaptables. La alineación de sus diseños con las directrices proporcionadas en este marco de trabajo debería impulsar una salud de mayor calidad y más duradera en sus aplicaciones Salesforce Customer 360. 💡 ¿Desea empezar a trabajar con patrones y antipatrones rápidamente? Visite el [Explorador de patrones](/docs/architect/es-mx/well-architected-tools/guide/patterns) y antipatrones. A continuación, puede ver una descripción general de cómo se organizan los temas:

Confiable
Una solución de confianza protege su negocio y a las partes interesadas.
Seguro	Cumplimiento	Fiable
Seguridad organizativa Seguridad de sesión Seguridad de datos	Adhesión legal Estándares éticos Accesibilidad	Disponibilidad Desempeño Escalabilidad
Fácil
Una solución sencilla entrega valor de negocio rápidamente.
Intencionado	Automatizado	Participación
Estrategia Mantenibilidad Legibilidad	Eficiencia Integridad de datos	Simplificado Útil
Adaptable
Una solución adaptable evoluciona con su negocio.
Resistente		Componible
Gestión del ciclo de vida de aplicaciones Respuesta de incidente Planificación de continuidad		Separación de preocupaciones Interoperabilidad Capacidad de empaquetado

> Lea sobre nuestras programaciones de actualizaciones [aquí](/docs/architect/es-mx/well-architected/guide/contributors). # Introducción Una solución de Salesforce que es **fácil** entrega valor rápidamente. Una solución bien diseñada para ser **fácil** es intencionada, automatizada y atractiva. Las soluciones **intencionadas** entregan valor de negocio inmediatamente y a lo largo del tiempo.
Las soluciones **automatizadas** permiten al negocio realizar el trabajo con mayor rapidez y a escala.
Las soluciones **implicativas** encantan a los usuarios e impulsan la adopción.
La creación de arquitecturas que sean **fáciles** puede plantear retos complejos para un arquitecto. Dada la flexibilidad de Salesforce Platform y la variedad de [herramientas de automatización](/docs/architect/es-mx/well-architected/guide/automated#herramientas-relevantes-para-automatizados) disponibles, los detalles de implementación pueden variar ampliamente entre organizaciones de Salesforce individuales. Las arquitecturas **fáciles** pueden requerir análisis de compensación más inteligentes (y difíciles) y pláticas con sus partes interesadas. Un diseño de solución podría ser resistente y fiable para un programador, pero no sencillo de poseer o mantener para un administrador de la organización. Tal solución no estaría bien diseñada para ser **fácil**. Para llegar a una solución **fácil**, debe comprender las prioridades de negocio de forma profunda y precisa. Debe comprender sus usuarios, incluyendo sus preferencias, sus necesidades y las realidades diarias de su trabajo. También debe comprender las habilidades (y las brechas de habilidades) en sus equipos de entrega y mantenimiento. Tendrá que iterar a través de diferentes opciones de herramientas y patrones de diseño para llegar a una solución que sea intencionada para obtener valor para el negocio mientras es gestionable para equipos de entrega y mantenimiento, automatiza el trabajo más rápido y a escala y realmente implica a los usuarios. Las siguientes secciones proporcionan directrices más detalladas para consideraciones principales de una arquitectura de soluciones **fáciles**. ## Descripción general sencilla

Intencionado
Las soluciones intencionadas entregan valor de negocio inmediatamente y a lo largo del tiempo. Las arquitecturas intencionales se planifican y se entregan de forma estratégica, se pueden mantener de forma efectiva y son fáciles de leer y comprender para los humanos.
Estrategia	Mantenibilidad	Lectura
Priorización Hoja de ruta Gobernanza	Estándar frente a Personalizado Deuda técnica	Estándares de diseño Documentación
Automatizado
Las soluciones automatizadas permiten al negocio realizar el trabajo con mayor rapidez y a escala. La automatización saludable reduce el tiempo empleado en tareas manuales repetitivas o entrada de datos compleja.
Eficiencia	Integridad de datos
Diseño de procesos Lógica operativa KPIs	Gestión de datos Tratamiento de errores
Participación
Las soluciones atractivas encantan a los usuarios e impulsan la adopción. La arquitectura para la implicación significa crear experiencias de usuario útiles e intuitivas.
Simplificado	Útil
Complejidad de aplicación Formularios Factor de forma	Notificaciones y mensajería Directrices en aplicación Reconocimiento y recompensas

> Lea sobre nuestras programaciones de actualizaciones [aquí](/docs/architect/es-mx/well-architected/guide/contributors). ## Introducción Las soluciones fiables funcionan de forma efectiva y fiable. Están disponibles, tienen un desempeño coherente y se amplían para dar cobertura a negocios en crecimiento. Un sistema fiable no es proclive a errores, se comporta según lo esperado y proporciona resultados de forma oportuna. Por el contrario, un sistema poco fiable es lento, no se comporta según lo esperado o falla en momentos críticos. Los sistemas poco fiables proporcionan información imprecisa, de modo que las partes interesadas no pueden Trust en ellos para decisiones de negocio. La fiabilidad del sistema no es constante. Un sistema fiable hoy en día puede dejar de ser fiable si no está diseñado para el crecimiento. Un sistema poco fiable puede requerir mantenimiento, refactorización o reimplementación costosos, desviando fondos de proyectos estratégicos. Mejore la fiabilidad de sus soluciones de Salesforce centrándose en tres principios: [disponibilidad](/docs/architect/es-mx/well-architected/guide/reliable#disponibilidad), [desempeño](/docs/architect/es-mx/well-architected/guide/reliable#desempeño) y [escalabilidad](/docs/architect/es-mx/well-architected/guide/reliable#escalabilidad). [El conjunto de productos](https://www.salesforce.com/platform/application-scaling-performance-testing/) de capacidad de ampliación de Salesforce proporciona funciones nativas para ayudar los arquitectos a poner en marcha implementaciones fiables. ## Disponibilidad La disponibilidad es una medición del porcentaje de tiempo que su sistema está operativo. Salesforce Platform gestiona la mayoría de los problemas de disponibilidad [a nivel de infraestructura](https://trust.salesforce.com/). Sin embargo, la disponibilidad de las soluciones que crea en la plataforma, y que experimentan sus clientes, es una responsabilidad compartida. Es importante comprender que incluso con la [alta disponibilidad](https://trust.salesforce.com/en/#systemStatus) de Salesforce, el riesgo de interrupción del servicio nunca es cero. Los arquitectos deben prepararse para interrupciones del servicio de Salesforce como mantenimiento planificado o circunstancias imprevistas. Además de las interrupciones del servicio, considere cómo mantener un alto desempeño y crecer con el negocio. Las opciones arquitectónicas estrechas pueden provocar problemas de disponibilidad a largo plazo. Piense en la disponibilidad durante la fase de diseño, _antes_ de crear su solución. Cuanto más aplace la arquitectura para la disponibilidad, mayor será el costo real de los problemas de disponibilidad a largo plazo. Para mitigar posibles riesgos, utilice Prueba de escala Salesforce en su entorno de prueba. En ese entorno, puede realizar pruebas a escala de producción antes de implementar código en producción. Los arquitectos utilizan el lenguaje del negocio, enmarcando preocupaciones técnicas para las partes interesadas del negocio para obtener buy-in y priorizar el trabajo de disponibilidad. Para mitigar posibles riesgos, utilice Prueba de escala Salesforce en su entorno de prueba. En ese entorno, puede realizar pruebas a escala de producción antes de implementar código en producción. Puede diseñar para una mayor disponibilidad de sus soluciones de Salesforce a través de la [gestión de riesgos](/docs/architect/es-mx/well-architected/guide/reliable#gestión-de-riesgos) y la [mitigación de fallos](/docs/architect/es-mx/well-architected/guide/reliable#mitigación-de-fallos). ### Gestión de riesgos La gestión de riesgos en el contexto de la arquitectura de Salesforce implica identificar posibles peligros para el funcionamiento de su sistema; sus usuarios, incluyendo empleados, socios y clientes); y sus procesos de negocio. A menudo, el proceso formal de realizar análisis de riesgo recae en las responsabilidades de los gestores de proyectos. Como arquitecto, asegúrese de que el análisis de riesgos representa adecuadamente las preocupaciones de las partes interesadas técnicas y de negocio. También es su responsabilidad identificar los casos de uso críticos de negocio para los que necesita realizar pruebas de escala basándose en sus puntos críticos de pico de producción. Algunos de los mayores riesgos en la gestión de riesgos provienen de no dedicarle suficiente tiempo y reflexión. Los equipos a menudo omiten la evaluación de riesgos O combinan la solución para la [copia de seguridad y restauración](/docs/architect/es-mx/well-architected/guide/resilient#creación-de-funciones-de-copia-de-seguridad-y-restauración), una parte importante de la mitigación de riesgos para la integridad de los datos, con una evaluación y mitigación de riesgos integral. Para evaluar el riesgo para sus soluciones de Salesforce, utilice estos métodos: - **Utilice un marco** de evaluación de riesgos. Es posible que algunas grandes empresas ya dispongan de matrices de riesgo relevantes. Si la suya sí, utilícelas para determinar cómo clasificar los peligros, qué tipos de información recopilar, qué necesita establecer para la reparación y mucho más. Si aún no tiene un marco de trabajo de evaluación de riesgos, busque uno de un origen de buena reputación y utilícelo. - **Evalúe la gravedad del impacto y las categorías de riesgo desde la perspectiva de sus clientes**. Proactive Monitoring y Scale Center proporcionan tableros y alertas configurables. Evalúan continuamente los riesgos de desempeño y capacidad de ampliación y reducen su dependencia de listas de comprobación manuales. Customer Trust y percepción son clave para cada negocio. En términos de repercusión de negocio, los riesgos para problemas que llegan a los clientes normalmente superan los riesgos para problemas que no. Es posible que los clientes no piensen o perciban riesgos del mismo modo que los equipos internos. Si un cliente no puede iniciar sesión en su cuenta, probablemente no le importe la causa raíz del problema. Se preocupan más por su propia experiencia inmediata. - **Priorice sus riesgos**. Idealmente, cada riesgo está vinculado a un plan de mitigación y respuesta sólido. En realidad, tendrá brechas que debe solucionar con el tiempo. Es importante adoptar un enfoque de “entregar valor de forma temprana e iterar”. Usted y sus equipos de entrega y mantenimiento solo pueden asumir mucho trabajo en un momento dado. En Salesforce, una expresión común es: “Si todo es importante, nada es importante”. Utilizamos V2MOM para priorizar y alinear el trabajo en toda la compañía, entre equipos y hasta cada individuo. (Puede [obtener más información](https://trailhead.salesforce.com/content/learn/modules/manage_the_sfdc_organizational_alignment_v2mom/msfw_oav2m_writing_a_v2mom) sobre los V2MOM en Trailhead.) Utilice sus evaluaciones de riesgo, que le dan la oportunidad de trabajar con sus partes interesadas en la prioridad y el compromiso con el trabajo de gestión de riesgos más importante. Utilice Prueba de escala - Creación de plan de prueba para identificar los riesgos a priorizar y mitigar esos riesgos utilizando pruebas de escala. Utilice Proactive Monitoring para detectar riesgos de disponibilidad temprana. Aflora anomalías como picos de límite de solicitudes de API, errores de bloqueo de filas o fallos Apex simultáneos, proporcionando perspectivas sobre las que se pueden realizar acciones antes de que los problemas se conviertan en interrupciones del servicio. Los [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/reliable#patrones-de-disponibilidad-y-antipatrones) de disponibilidad muestran una gestión de riesgos adecuada y deficiente en una solución de Salesforce. Utilice los patrones para validar sus diseños antes de construir o para identificar áreas de refactorización en su sistema. Para obtener más información acerca de herramientas de Salesforce relacionadas con la gestión de riesgos, consulte [Herramientas de Salesforce para fiabilidad](/docs/architect/es-mx/well-architected/guide/reliable#herramientas-de-salesforce-para-la-fiabilidad). ### Mitigación de fallos Un punto de fallo es una vulnerabilidad que hace que un sistema no sea fiable. Una buena mitigación de fallos no consiste en precisar cada posible punto de fallo. En su lugar, se trata de clasificar y priorizar rápidamente puntos de fallo de modo que los equipos de mantenimiento y asistencia puedan responder de forma efectiva. Consulte [Respuesta de incidente](/docs/architect/es-mx/well-architected/guide/resilient#respuesta-de-incidente). Para desarrollar mejores estrategias de mitigación de fallos: - **Clasifique desencadenadores para puntos de fallo en términos de personas, procesos y tecnología**. Del mismo modo que categoriza riesgos en términos de personas, procesos y tecnología, aplique el mismo pensamiento a cómo se desencadenan puntos de fallo de alta prioridad. Este enfoque le ayuda a identificar posibles desencadenadores de fallos y desarrollar y organizar respuestas a ellos. A veces, puede mitigar desencadenadores de fallos aparentemente divergentes con enfoques de mitigación similares, basándose en cómo se clasifican los desencadenadores.

Clasificación/tipo de desencadenador	Mitigación
Personas	Política
Proceso	Libros de jugadas, planes de continuidad
Tecnología	Redundancia

- **Identifique el aspecto de la mitigación básica, intermedia y madura**. Llevará tiempo elaborar estrategias de mitigación. Defina los niveles de mitigación para ayudarle a usted y a su equipo a ver dónde puede establecer controles inmediatamente y cómo centrar sus esfuerzos a lo largo del tiempo. Busque siempre oportunidades para utilizar la automatización en sus enfoques de mitigación lo antes posible. Para ilustrar el aspecto de este enfoque en la práctica, este ejemplo muestra un desencadenador orientado a las personas y el aspecto de la mitigación basada en políticas en niveles básicos, intermedios y maduros.

Desencadenador	Mitigación	Básico	Intermedio	Maduro
Cambio de acceso de usuario para un empleado nuevo o saliente	Acuerdo de nivel de servicio (SLA) y requisitos para aprovisionar o desaprovisionar usuarios	Aprovisione y desaprovisione usuarios manualmente, según los SLA para cambios manuales.	Procese los cambios de usuario a través de trabajos programados, según los SLA para cambios programados.	Automatice el aprovisionamiento y desaprovisionamiento de usuarios a través de una solución de SSO/IDM.

Además de utilizar libros de jugadas de arquitectura y planificación de continuidad, utilice Proactive Monitoring. Con Proactive Monitoring, puede configurar alertas en tiempo real sobre desencadenadores de fallos, como fallos de inicio de sesión, excepciones de tiempo de espera de CPU o errores de solicitud de API simultáneos. Este enfoque de alerta aumenta la mitigación de fallos garantizando que tanto las partes interesadas técnicas como de negocio estén informadas a tiempo para reducir la repercusión de los fallos. Los [patrones y antipatrones de disponibilidad](/docs/architect/es-mx/well-architected/guide/reliable#patrones-de-disponibilidad-y-antipatrones) muestran el aspecto adecuado y deficiente de la mitigación de fallos en una solución de Salesforce. Utilícelos para validar sus diseños antes de construir o para identificar lugares en su sistema para refactorizar. Para obtener más información acerca de las herramientas de Salesforce para la mitigación de fallos, consulte [Herramientas relevantes para fiable](/docs/architect/es-mx/well-architected/guide/reliable#herramientas-de-salesforce-para-la-fiabilidad). ### Patrones de disponibilidad y antipatrones Esta tabla muestra una selección de patrones para buscar o crear en su organización, y antipatrones para evitar o dirigir para su corrección. ✨ Descubra más patrones de disponibilidad en el [Explorador de patrones](/docs/architect/es-mx/well-architected-tools/guide/trusted-availability) y antipatrones.

	Patrones	Antipatrones
Gestión de riesgos	En su negocio: - Se está utilizando un marco de trabajo de evaluación de riesgos establecido. - Los riesgos se categorizan en personas, procesos y áreas de tecnología.	En su negocio: - El marco de trabajo de evaluación de riesgos para Salesforce es ad hoc. - Los riesgos no están claramente identificados.
Gestión de riesgos	En su documentación: - La gravedad del riesgo se categoriza y evalúa en base a la repercusión sobre el cliente. - Se priorizan los planes de respuesta y mitigación de riesgos.	En su documentación: - La perspectiva del cliente no se tiene en cuenta al evaluar la gravedad o categoría del riesgo. - Los planes de respuesta y mitigación de riesgos intentan capturar todos los riesgos imaginables.
Mitigación de fallos	En su organización: - Los desencadenadores de puntos de fallo y sus planes de mitigación correspondientes se categorizan por personas, procesos y tecnología. - Los controles de mitigación se establecen de inmediato, maduran con el tiempo e incorporan la automatización lo antes posible. - Para garantizar una escalabilidad óptima, las pruebas y la optimización integrales se completan antes de que se publiquen los cambios en producción. - Antes de eventos críticos de negocio, se realizan pruebas de escala y optimización, según los SLA.	En su organización: - Los desencadenadores de punto de fallo no están clasificados. Los enfoques de mitigación no existen o solo se utilizan ad hoc. - Los controles de mitigación no se vuelven a visitar ni se mejoran. - La automatización no se utiliza en la mitigación.
Seguimiento y observabilidad	En su organización: - Para comprobaciones y detección de anomalías, Proactive Monitoring está activado. - Para visibilidad continua, las alertas Proactive Monitoring están integradas con Scale Center.	En su organización: -Solo se realizan comprobaciones de estado manuales y no existe ningún monitoreo continuo.

## Desempeño El desempeño de la arquitectura del sistema es una medición de cuánto procesa un sistema (rendimiento) y cuán rápido responde (latencia). Normalmente comprende el desempeño de su sistema a través de pruebas de producción y monitoreo. Un sistema con desempeño completa los procesos de forma oportuna en cada nivel de demanda previsto. El mal desempeño va de la mano con una latencia más alta y un menor rendimiento, lo que lleva a una productividad más baja y una mayor frustración de los usuarios. Solucionar problemas de desempeño es urgente porque pueden llevar a una pérdida de Customer Trust y pérdidas financieras. Puede mejorar el desempeño de sus soluciones optimizando el rendimiento y la latencia. > Nota: La optimización del rendimiento y la latencia son aspectos esenciales para mejorar el procesamiento y la capacidad de respuesta del sistema. Sin embargo, es importante recordar que el desempeño general del sistema también depende de lo bien que diseñe para [la escala](/docs/architect/es-mx/well-architected/guide/reliable#escalabilidad). Debe tener en cuenta ambas dimensiones en sus diseños. ### Rendimiento En el contexto de la arquitectura de Salesforce, el rendimiento es el número de solicitudes simultáneas que un sistema puede completar en un intervalo de tiempo concreto. Las soluciones de Salesforce de los clientes diseñadas y optimizadas para el rendimiento funcionan mejor dentro de los [límites reguladores](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) integrados de Salesforce Platform. La optimización del rendimiento en Salesforce comienza con el cálculo preciso de las cargas de trabajo en su sistema y la planificación de su crecimiento. Sin proyecciones precisas para las demandas que se realizarán en el sistema, no puede precisar posibles problemas con las funciones de rendimiento de su sistema. Cuando piense en cargas de trabajo, tenga en cuenta estas tres dimensiones. - **El número de transacciones** que su sistema debe procesar en una cantidad de tiempo determinada - **El número de usuarios** que deben acceder a su sistema simultáneamente - **La complejidad general de la lógica de transacciones** en el sistema Cuando se piensa en el desempeño, los equipos a veces se centran demasiado en la computación y las restricciones en el tiempo máximo de CPU, que están entre los límites reguladores de la plataforma. Los equipos con un enfoque restringido en el tiempo de CPU pasan por alto otros métodos para optimizar el rendimiento. Ampliar su enfoque y aplicar estos métodos mejora el rendimiento y la eficiencia generales de su arquitectura de Salesforce. Esas mejoras, a su vez, ayudarán a reducir la latencia y aumentar el desempeño general del sistema. ApexGuru detecta de forma proactiva antipatrones que limitan el rendimiento como SOQL en bucles, DML en bucles, llamadas GGD ineficientes y métodos costosos. Estas perspectivas ayudan a los equipos a eliminar los riesgos de límite regulador que limitan el rendimiento. Para optimizar el rendimiento en su sistema: - **Favorezca el procesamiento asíncrono**. Salesforce Platform utiliza contextos de transacciones para controlar la integridad de los datos y limitar el código desbocado. Consulte [transacciones en Fundamentos de arquitectura](/docs/architect/es-mx/fundamentals/guide/architecture-basics#transacciones) en Fundamentos de arquitectura. Por este motivo, el uso de procesamiento asíncrono (asincrónico) donde sea posible puede ayudar a minimizar posibles cuellos de botella en contextos de ejecución síncronos. Consulte [Tratamiento de datos](/docs/architect/es-mx/well-architected/guide/automated#gestión-de-datos). El uso de computación asíncrona no es una cura para cada tipo de problema de desempeño, y deberá tener en cuenta la latencia al incorporar procesos asíncronos. Ciertas funciones de plataforma, como Apex colocable en cola, pueden aumentar la latencia durante picos de tráfico porque hacen que los mensajes esperen más en una cola. Dependiendo de su caso de uso, puede decidir tolerar una posible disminución de la capacidad de respuesta para mantener o mejorar el rendimiento. En otros casos, puede decidir que el aumento de la latencia no es aceptable. Con Prueba de escala, puede validar estas compensaciones simulando picos de tráfico en un Sandbox completo. Allí, puede medir cómo afectan los trabajos al rendimiento y la latencia. - **Utilice siempre masificación**. En un nivel alto, masificación significa realizar operaciones contra cobros. A menudo, los equipos que debaten la masificación para sus soluciones de Salesforce se centran en la simplificación de las operaciones de datos frente a recopilaciones. Consulte [Lógica operativa](/docs/architect/es-mx/well-architected/guide/automated#lógica-operativa). Sin embargo, la masificación a nivel del sistema implica algo más que operaciones de datos. Considere también ciertas tareas, como llamadas o cálculos complejos, como candidatas para la masificación. El masificado adecuado reduce los gastos generales. Ejecuta múltiples operaciones con una solicitud en vez de una solicitud por operación. ApexGuru aflora patrones antimasificación como [DML o SOQL dentro de bucles](https://help.salesforce.com/s/articleView?language=en_US&id=xcloud.apexguru_antipatterns.htm&type=5), que puede solucionar antes de ampliar a producción. Consulte [Operaciones masivas](/docs/architect/es-mx/fundamentals/guide/platform-multitenant-architecture#operaciones-masivas). - **Utilice SOSL para búsquedas y trate SOQL como una operación de datos**. Puede parecer obvio que el uso de declaraciones SOQL demasiado complejas aumentará la cantidad de tiempo que tarda el sistema en recuperar registros. SOQL agrega sobrecarga a la [base de datos relacional subyacente](/docs/architect/es-mx/fundamentals/guide/platform-multitenant-architecture#la-capa-de-datos-de-plataforma), ralentizando el procesamiento. Al utilizar criterios de texto o comodines, SOSL tiene un mayor desempeño. SOSL utiliza el motor de búsqueda de la plataforma, que está optimizado para el indexado de texto completo y las búsquedas universales. Para optimizar los patrones de recuperación de registros, asegúrese de que sus estándares de diseño especifican cuándo utilizar SOSL para encontrar datos en su sistema. Asegúrese también de que especifican cómo utilizar SOQL para operaciones de datos eficientes. Consulte [Lógica operativa](/docs/architect/es-mx/well-architected/guide/automated#lógica-operativa)). - **Utilice Caché de plataforma y ApexGuru**. La capa de [caché Lightning Platform](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_cache_namespace_overview.htm) proporciona un desempeño más rápido y una mejor fiabilidad al almacenar en caché datos de sesión y organización de Salesforce. Caché de plataforma mejora el desempeño distribuyendo espacio en caché de modo que algunas aplicaciones u operaciones no roban capacidad a otras. ApexGuru detecta oportunidades perdidas para almacenar en caché consultas repetidas (por ejemplo, [Caché de plataforma para resultados SOQL](https://help.salesforce.com/s/articleView?id=xcloud.apexguru_antipattern_soql_without_platform_cache.htm&type=5)), lo que mejora el rendimiento en entornos de alta escala. Los [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/reliable#patrones-de-desempeño-y-antipatrones) para el desempeño muestran el aspecto apropiado y pobre del desempeño en una organización de Salesforce. Utilícelos para validar sus diseños antes de construir o para identificar oportunidades para una optimización adicional. Para obtener más información acerca de las herramientas de Salesforce para la optimización del rendimiento, consulte [Herramientas de Salesforce para fiabilidad](/docs/architect/es-mx/well-architected/guide/reliable#herramientas-de-salesforce-para-la-fiabilidad). ### Latencia La latencia es una medición de la rapidez con la que un sistema completa una ruta de ejecución. La optimización del rendimiento de su sistema contribuirá a mejorar la latencia. Otra dimensión de la latencia es el desempeño percibido o la capacidad de respuesta del sistema para los usuarios. Las personas no desean esperar a que se carguen las páginas o que finalicen los procesos. Los usuarios de su sistema se frustrarán si experimentan con frecuencia tiempos de carga prolongados al intentar navegar por vistas de lista, páginas de registro, reportes, etc. Cuando esto sucede, los clientes o socios pueden decidir llevar su negocio a otro lugar en vez de tratar con sistemas de mal desempeño. Internamente, los empleados pueden crear soluciones para evitar el uso del sistema como está diseñado, lo que puede causar problemas descendentes para la seguridad y la integridad de los datos. El desempeño percibido puede ser difícil de diagnosticar. Cuando un usuario reporta un desempeño lento, es posible que los equipos de asistencia no puedan reproducir el problema. El aumento de la latencia es a menudo el resultado de una combinación de problemas más pequeños que se basan entre sí, lo que puede dificultar el diagnóstico de la causa exacta de problemas de desempeño percibidos. Para reducir la latencia y mejorar la capacidad de respuesta en su sistema de Salesforce: - **Optimice reportes**. Asegúrese de que cada reporte tiene un único propósito específico. Identifique claramente la audiencia y el propósito de cada reporte en su sistema. En reportes, incluya solo la cantidad mínima de datos que los miembros de la audiencia necesitan para tomar decisiones. La eliminación de columnas que no se alinean con el propósito de un reporte mejorará el desempeño del reporte reduciendo la cantidad de datos que se deben recuperar y mostrar. - **Optimice filtros**. Los filtros efectivos aceleran el desempeño de reportes y vistas de lista al definir con precisión el número de filas que se recuperan de la base de datos. Como regla general, cuanto más específica sea su lógica de filtro, más eficiente será la consulta subyacente para los datos. Las formas de optimizar filtros incluyen: - Uso de “igual a” y “no igual a” en vez de “contiene” y “no contiene” - Evitar el filtrado por campos de fórmula - **Simplifique su modelo** de colaboración. Un modelo de colaboración demasiado complejo puede ralentizar una variedad de procesos porque el sistema debe comprobar el modelo de colaboración y visibilidad para determinar si un usuario tiene acceso a los datos para mostrar o procesar. Los cálculos de colaboración complejos pueden aumentar la latencia en la creación de reportes, vistas de lista y automatización que se ejecutan en el contexto del usuario. Consulte [Compartir y visibilidad](/docs/architect/es-mx/well-architected/guide/secure#colaboración-y-visibilidad). - **Optimice componentes personalizados** de la interfaz de usuario. Los componentes de interfaz de usuario (UI) creados a medida pueden aumentar la latencia. Para optimizar el desempeño en componentes de la interfaz de usuario personalizados, considere hacer estas cosas. - **Utilice Componentes web Lightning (LWC)**. El marco de trabajo de LWC está estrechamente alineado con los estándares web modernos. Los componentes personalizados escritos en LWC se representan de forma más eficiente en navegadores web y permiten a los desarrolladores utilizar métodos JavaScript de mayor desempeño. Intente siempre utilizar LWC en vez de tecnologías de interfaz de usuario antiguas, como Aura o Visualforce. - **Utilice Lightning Data Service**. Lightning Data Service gestiona la creación y el mantenimiento de caché seguro, de desempeño y compartido entre componentes. Utilícelo para evitar recorridos de ida y vuelta innecesarios al servidor para datos, y para aumentar la capacidad de respuesta general de la aplicación. - **Utilice la clasificación y el filtrado del lado del cliente para datos de lista**. Tanto para componentes LWC (preferidos) como Aura (de lo contrario), los desarrolladores pueden utilizar funciones de matriz JavaScript estándar para ordenar, filtrar y seleccionar valores en el lado del cliente, reduciendo el número de viajes requeridos al servidor. Los [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/reliable#patrones-de-desempeño-y-antipatrones) muestran el aspecto apropiado y la latencia deficiente en una organización de Salesforce. Utilícelos para validar sus diseños antes de construir o para identificar oportunidades para una optimización adicional. Para obtener más información acerca de las herramientas de Salesforce para la optimización de la latencia, consulte [Herramientas de Salesforce para fiabilidad](/docs/architect/es-mx/well-architected/guide/reliable#herramientas-de-salesforce-para-la-fiabilidad). ### Patrones de desempeño y antipatrones Esta tabla muestra una selección de patrones para buscar o crear en su organización, y antipatrones para evitar o dirigir para su corrección. ✨ Descubra más patrones de desempeño en el [Explorador de patrones](/docs/architect/es-mx/well-architected-tools/guide/trusted-performance) y antipatrones.

	Patrones	Antipatrones
Resultado	En sus estándares de diseño: - Directrices sobre cómo utilizar Caché de plataforma se adhiere a Mejores prácticas de Caché de plataforma	En sus estándares de diseño: - Si hay directrices para el uso de Caché de plataforma, no está claro o no se alinea con mejores prácticas.
Resultado	En su organización: - La masificación se utiliza para operaciones de datos y sistema. - Los métodos DML o de base de datos siempre operan contra recopilaciones en Apex. - Los campos utilizados durante DML para un tiempo transcurrido más corto en la base de datos están limitados. - Todos los criterios comodín se utilizan en SOSL. - Las declaraciones SOQL son selectivas.: -- No utilizan comparaciones LIKE o comparaciones de texto parcial. -- Los operadores de comparación utilizan lógica positiva (es decir, INCLUDES o IN) como su lógica principal o única lógica. -- = NULL y != NULL se utilizan solo rara vez siempre sigue un operador de comparación positivo. – Para minimizar la carga de datos y maximizar el desempeño, solo se recuperan los campos necesarios en consultas SOQL. -- No se utilizan declaraciones LIMIT 1. -- No se utiliza la palabra clave TODAS LAS FILAS. - Se favorece el procesamiento asíncrono siempre que sea posible. - Las particiones de Caché de plataforma están configuradas.	En su organización: - Las declaraciones DML no se masifican. - Los métodos DML o de base de datos operan con registros únicos en Apex. - SOSL rara vez o no se utiliza de forma coherente para criterios de selección de comodines. - Las declaraciones SOQL no son selectivas: -- Incluyen criterios de filtro Me gusta y Comodín. -- Las comparaciones que utilizan criterios !=, NOT o NOT IN se utilizan como el operador de comparación principal o único. -- Utiliza criterios = NULL y != NULL como operadores de comparación principales o únicos. -- Se utilizan instrucciones LIMIT 1. -- Se utiliza la palabra clave ALL ROWS. - SOQL aparece en bucles. - Se favorecen los procesos síncronos.
Latencia	En su organización: - Los reportes tienen un único propósito específico y contienen el número mínimo de filas y columnas necesarias para tomar decisiones. - Los filtros utilizan “igual a” y “no igual a”. - Los filtros no contienen campos de fórmula. - Los modelos de colaboración se simplifican al máximo. - Los componentes personalizados de la interfaz de usuario utilizan Componentes web Lightning (LWC). - LWC utiliza Lightning Data Service para operaciones de datos. - La clasificación y filtrado de datos de lista se gestiona en el lado del cliente en JavaScript. - Salesforce Edge está activado.	En su organización: - Los reportes sirven para múltiples fines o contienen filas y columnas adicionales que no son necesarias para tomar decisiones. - Los filtros utilizan “contiene” y “no contiene”. - Los filtros contienen campos de fórmula. - Los modelos de colaboración son complejos. - Los componentes personalizados de la interfaz de usuario utilizan marcos que pueden dar como resultado una representación menos eficiente que LWC (por ejemplo, Aura o Visualforce). - LWC utiliza Apex para operaciones de datos. - La clasificación y filtrado de datos de lista se gestiona en el lado del servidor utilizando Apex. - Salesforce Edge no está activado.

## Escalabilidad La capacidad de ampliación es la capacidad de un sistema de desempeñarse de forma coherente a medida que evoluciona y crece. Un sistema ampliable gestiona grandes aumentos en volúmenes de transacciones o acceso simultáneo sin cambios fundamentales. Los servicios de plataforma de Salesforce están diseñados para admitir la capacidad de ampliación de aplicaciones. Consulte [Procesamiento de plataforma interno](/docs/architect/es-mx/fundamentals/guide/platform-multitenant-architecture#procesamiento-de-plataforma-interno). Dicho esto, a medida que su organización crece y la demanda de sus productos y servicios aumenta, usted es responsable de crear un sistema que pueda tener un desempeño efectivo y según lo esperado. La arquitectura para la capacidad de ampliación desde el principio da como resultado una entrega más rápida de nuevas funciones y menos interrupciones de servicio a medida que aumenta el tráfico de usuarios. Al principio de la fase de diseño, antes de implementar nuevas funciones en producción, utilice **Prueba de escala** para simular cargas de trabajo proyectadas y validar que la arquitectura puede ampliarse para admitirlas. Los sistemas no diseñados para la capacidad de ampliación requieren la solución de problemas, el rediseño y la refactorización constantes y costosos. Los problemas de escalabilidad se agravan con el tiempo, lo que degrada el desempeño en todo el sistema. En algunos casos, los negocios se encuentran gastando la mayoría de los recursos de desarrollo y mantenimiento en solucionar problemas de escalabilidad en vez de en nuevas funciones que crean valor. A veces, un negocio alcanza un punto de inflexión crítico. El diseño original de su sistema no puede admitir el crecimiento del negocio y los eventos inesperados hacen que el sistema sea inestable. Utilice perspectivas desde **Centro de escala** para identificar puntos de inflexión de escalabilidad de forma temprana. Scale Center aflora puntos críticos de excepción, transacciones de larga ejecución y cuellos de botella de cola que empeoran con el tiempo. Puede diseñar mejor la escala centrándose en la optimización del modelo de datos y la gestión del volumen de datos. _Nota: Aunque no se trata aquí, las pruebas de escalabilidad son una parte crítica de la validación de sus arquitecturas de aplicación. Para obtener orientación, consulte [Estrategia de prueba](/docs/architect/es-mx/well-architected/guide/resilient#estrategia-de-prueba)._ ### Modelado de datos El modelado de datos implica estructurar los objetos en su organización y relacionarlos entre sí de una forma que permita a sus usuarios y procesos automatizados recuperar los datos que necesitan lo más rápido posible. Realizar pasos para [mejorar el desempeño](/docs/architect/es-mx/well-architected/guide/reliable#rendimiento) soluciona muchos problemas de desempeño, pero sus esfuerzos no serán tan efectivos sin un modelo de datos optimizado. Las repercusiones negativas de un modelo de datos mal diseñado no se notan de inmediato; sus debilidades se exponen a medida que el sistema crece en términos de volumen de datos, procesos, usuarios e integraciones. Un modelo de datos bien diseñado facilita la tarea de refactorizar continuamente su aplicación a medida que se agregan y amplían los requisitos. **ApexGuru** aflora antipatrones de acceso a datos como SOQL no selectivo, campos no utilizados e ineficiencias de esquemas que afectan directamente a la capacidad de ampliación del modelo de datos. Para optimizar su modelo de datos: - **Utilice los modelos de datos preintegrados desde Salesforce**. Salesforce proporciona modelos de datos preintegrados para Ventas, Servicio y una variedad de verticales de la industria. El uso de los modelos de datos proporcionados por Salesforce garantiza que las funciones en su sistema se definan solo una vez, eliminando la redundancia y los silos y estableciendo una única fuente de verdad en todo el sistema. Como utilizó modelos de datos preintegrados de Salesforce para ese único origen, es más fácil comprender los datos de la aplicación con análisis y utilizar los servicios de inteligencia artificial preintegrados de Salesforce. Además, la reducción de las personalizaciones que debe admitir reduce los costos de mantenimiento y la deuda técnica. - **Seleccione los tipos de datos** correctos. Comprenda los diferentes tipos de campos admitidos por Salesforce y sus limitaciones. Considere los requisitos de creación de reportes y cifrado de modo que pueda evitar tener que convertir datos entre tipos en el futuro. - **Elija las relaciones correctas**. Salesforce admite dos tipos de relaciones entre objetos: principal-detalle y búsqueda. Las relaciones principal-detalle ofrecen dos beneficios principales. Una es las funciones de resumen integradas, que cuentan y agregan detalles desde registros secundarios. La otra es una función de eliminación en cascada integrada, a través de la cual la eliminación de un registro principal también elimina sus registros secundarios. Sin embargo, asegúrese de comprender las [implicaciones de colaboración](/docs/architect/es-mx/well-architected/guide/reliable#volumen-de-datos) y sesgo de datos de las relaciones principal-detalle antes de decidir utilizarlas. - **Desnormalizar para escala.** La normalización es el proceso de estructurar su modelo de datos para una redundancia de datos reducida y una integridad de datos mejorada. Desafortunadamente, la normalización a veces causa problemas de ampliación. Las tablas desnormalizadas pueden tener un mejor desempeño a escala, pero recuerde tener en cuenta la integridad y la redundancia de los datos. Los [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/reliable#patrones-de-escalabilidad-y-antipatrones) muestran el aspecto adecuado y deficiente de la optimización del modelo de datos en una organización de Salesforce. Utilícelos para validar sus diseños antes de construir o para identificar oportunidades para una optimización adicional. Para obtener más información acerca de herramientas de Salesforce para la optimización de modelos de datos, consulte [Herramientas de Salesforce para fiabilidad](/docs/architect/es-mx/well-architected/guide/reliable#herramientas-de-salesforce-para-la-fiabilidad). ### Volumen de datos El volumen de datos es una medición de la cantidad de datos almacenados en su sistema, basándose en conteos y tamaños de registros. Si su organización tiene decenas de miles de usuarios, decenas de millones de registros o cientos de gigabytes de almacenamiento total de registros, tiene un gran volumen de datos. El volumen de datos y las relaciones entre objetos en su organización afectan a la capacidad de ampliación y probablemente tendrán un mayor impacto en la capacidad de ampliación que el número de registros solo. Para mejorar la capacidad de ampliación de organizaciones con grandes volúmenes de datos: - **Distribuya registros secundarios**. Evite el sesgo de datos principal-secundario garantizando que ningún principal tiene un gran número de registros secundarios. La recomendación general es que ningún principal debe tener más de 10.000 registros secundarios. Por ejemplo, en una implementación que tiene muchos contactos pero no utiliza cuentas, considere configurar varios registros de cuentas y distribuir registros de contactos relacionados entre ellos. - **Distribuya la propiedad de registros**. Evite el sesgo de propiedad asegurándose de que ningún usuario o cola posee, ni que todos los miembros de una única función o grupo público poseen, más de 10.000 registros del mismo objeto. “Estacionar” datos con un “usuario ficticio” es una práctica que a menudo lleva a un sesgo de propiedad. Si encuentra este problema, tenga en cuenta la repercusión que tendrá en los [cálculos de colaboración](/docs/architect/es-mx/well-architected/guide/reliable#latencia). Si no puede redistribuir registros para aliviar el sesgo de propiedad, evite asignar el usuario propietario de datos a una función. Si el modelo de colaboración de su organización requiere una asignación de funciones, coloque el usuario propietario de datos en una función distinta en la parte superior de la jerarquía de colaboración. No permita cambios frecuentes o no planificados en la función de ese usuario, ya que cualquier cambio tendrá repercusiones significativas en el desempeño debido a los nuevos cálculos de colaboración. Mantenga a ese usuario fuera de grupos públicos a los que se pueda hacer referencia en cualquier regla de colaboración. - **Reduzca la cantidad de datos de registros en Salesforce**. Salesforce está diseñado para proporcionar a los negocios una única vista de sus clientes. Puede parecer contradictorio que limitar datos en Salesforce sea una mejor práctica. Sin embargo, el poder de la vista única radica en lo bien que permite a los usuarios de negocio comprender y realizar acciones sobre datos de clientes. A medida que crece el volumen de datos, los datos que no son actuales o relevantes para los procesos o análisis diarios generan varios problemas. Esos problemas incluyen desempeño de aplicación degradado; riesgo de seguridad de datos aumentado; e impactos negativos en búsqueda, creación de reportes y análisis. Para evitar este tipo de problemas, defina un ciclo de vida de datos para cada objeto en su modelo de datos, con cronologías y clasificaciones para datos a medida que envejece y pierde valor de negocio inmediato. De acuerdo con el ciclo de vida de los datos, implemente estos procedimientos para gestionar los datos a lo largo del tiempo. - **Archivo y purga** de datos: Para mantener los volúmenes de datos lo más bajos posible, elimine los registros que no necesite el negocio para ayudar a mantener los volúmenes de datos lo más bajos posible. Utilice la función de eliminación permanente de la API masiva 2.0 para eliminar grandes volúmenes de datos. - **Agregación de datos:** cree objetos personalizados de agregación que resuma tendencias históricas clave o datos de resumen en un formato compatible con la creación de reportes. Rellene los objetos personalizados utilizando [Apex por lotes](/docs/architect/es-mx/well-architected/guide/reliable#rendimiento). Los usuarios pueden luego ejecutar reportes basándose en los registros de objetos agregados. - **Nivel de datos**. Mantenga grandes conjuntos de datos en una aplicación diferente si no son necesarios para reportes de Salesforce o el trabajo diario. Haga que los datos estén disponibles en Salesforce según sea necesario a través de mashups, llamadas u objetos externos. En la práctica, es posible que no siempre pueda solucionar inmediatamente la causa raíz de un problema de capacidad de ampliación cuando surgen problemas. Por este motivo, Salesforce proporciona opciones para ayudar a aliviar los puntos débiles inmediatos. Es importante saber que la activación de estas funciones en su organización no es una estrategia arquitectónica viable a largo plazo para tratar con grandes volúmenes de datos. Estas soluciones provisionales a corto plazo pueden ayudar a reducir la latencia en sistemas que sufren de una arquitectura de datos deficiente, pero también pueden agregar deudas técnicas a su organización. Las soluciones a corto plazo para problemas de escala incluyen: - **Índices personalizados Los** índices se almacenan en una tabla interna especial que el optimizador de consultas de la plataforma utiliza para acelerar las operaciones de acceso a los datos. Consulte [Índices de múltiples](/docs/architect/es-mx/fundamentals/guide/platform-multitenant-architecture#índices) arrendatarios). La plataforma indexa automáticamente ciertos tipos de campos de forma predeterminada. Para acelerar las consultas de bajo desempeño, puede solicitar índices personalizados adicionales haciendo contacto con el Servicio de atención al cliente de Salesforce. Utilice la herramienta Plan de consulta para determinar si los índices personalizados mejorarán el desempeño de sus consultas. - **Skinny tables**. Si necesita optimizar aún más las consultas para conjuntos comunes de campos en objetos con más de 1 millón de registros, las tablas reducidas pueden ayudar. Las tablas reducidas eliminan la [unión en segundo](https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_infrastructure_skinny_tables.htm) plano que se produce cuando se utilizan campos personalizados y estándar desde el mismo objeto en un reporte o una automatización. Para que pueda utilizar tablas reducidas, el Servicio de atención al cliente de Salesforce debe activarlas para su organización. Los [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/reliable#patrones-de-escalabilidad-y-antipatrones) para la capacidad de ampliación muestran el aspecto adecuado y deficiente de la gestión del volumen de datos en una organización de Salesforce. Utilícelos para validar sus diseños antes de construir o para identificar oportunidades para una optimización adicional. Para obtener más información acerca de herramientas de Salesforce para gestionar volúmenes de datos, consulte [Herramientas de Salesforce para fiabilidad](/docs/architect/es-mx/well-architected/guide/reliable#herramientas-de-salesforce-para-la-fiabilidad). ### Patrones de escalabilidad y antipatrones Esto muestra una selección de patrones para buscar o crear en su organización, y antipatrones para evitar o dirigir para su corrección. ✨ Descubra más patrones para la capacidad de ampliación en el [Explorador de patrones](/docs/architect/es-mx/well-architected-tools/guide/trusted-scalability) y antipatrones.

	Patrones	Antipatrones
Modelado de datos	En sus estándares de diseño: - Estándares y directrices para los que las justificaciones de negocio garantizan la existencia de un objeto personalizado.	En sus estándares de diseño: - No existen estándares para la creación de objetos personalizados.
	En su modelo de datos: - Los objetos estándar se utilizan cuando es posible. - Las comprobaciones de ApexGuru para antipatrones confirman que las consultas SOQL son selectivas y evitan un uso de esquemas ineficiente. - Las tablas se desnormalizan para la escala.	En su modelo de datos: - Tiene objetos estándar replicados. - Las tablas están normalizadas para evitar redundancias.
	Dentro de su negocio: - Los generadores de código bajo comprenden los diferentes tipos de campo admitidos por Salesforce, y evalúan los requisitos de creación de reportes y cifrado antes de seleccionar tipos de datos de campo. - Antes de decidir establecer una relación principal-detalle entre objetos, evalúa las implicaciones de colaboración y sesgo de datos de esa relación.	Dentro de su negocio: - Los generadores de código bajo seleccionan tipos de datos sin evaluar los requisitos de creación de reportes y cifrado descendentes. - Antes de decidir establecer relaciones principal-detalle entre objetos, no evalúa las implicaciones de colaboración y sesgo de datos de esa relación.
Volumen de datos	En sus datos: - Ningún registro principal tiene más de 10.000 registros secundarios. - No se asigna ningún usuario a más de 10.000 registros del mismo tipo de objeto. - Ninguna instancia incluye más de 10.000 registros que tengan campos de búsqueda apuntando al mismo registro. - Las cargas de datos masivas se ordenan en lotes según los valores de campo ParentId. - Para asegurarse de que las estrategias por lotes no se interrumpen bajo concurrencia, se utiliza Prueba de escala para validar patrones de carga masiva a escala de producción. - Las cargas de datos masivas en producción no se producen durante las horas de oficina pico. - Las cargas de datos masivas incluyen solo los datos mínimos necesarios para las decisiones de negocio.	En sus datos: - Existen registros con más de 10.000 registros secundarios. - Los usuarios están asignados a más de 10.000 registros del mismo tipo. - Existen instancias donde más de 10.000 registros tienen campos de búsqueda que apuntan al mismo registro. - Las cargas de datos masivas no se ordenan en lotes según los valores de campo ParentId. - Las cargas de datos masivas en producción se producen durante las horas de oficina pico. - Las cargas de datos masivas no están limitadas a los datos mínimos necesarios para las decisiones de negocio.
	En Flow y Apex: - Existe lógica para distribuir el número de registros secundarios entre múltiples registros principales en escenarios donde el sesgo de datos es un problema. - Al importar o replicar registros a través de la integración, la lógica los asigna a los usuarios humanos apropiados. - Para recopilaciones Apex, como listas y conjuntos, existe lógica para procesar múltiples registros para minimizar consultas y optimizar el tratamiento de datos. - Se redacta e implementa código Apex eficiente que sigue los estándares y mejores prácticas para código escalable.	En Flow y Apex: - Los registros secundarios se asignan arbitrariamente a registros principales, independientemente del número de registros secundarios que ya están asignados. - Los registros creados a través de cargas de datos o integraciones se asignan a un "usuario de integración" genérico. - Múltiples consultas SOQL recursivas desde el mismo objeto están en transacciones síncronas, lo que lleva a un alto uso de pila. Cuando los desarrolladores redactan código Apex, introducen ineficiencias y antipatrones de desempeño.
	Dentro de su negocio: - Documentó e implementó una estrategia de archivado y purga de datos	Dentro de su negocio: - No tiene una estrategia de archivado y purga de datos o su estrategia se documentó pero no se implementó

## Herramientas de Salesforce para la fiabilidad

Herramienta	Descripción	Desempeño	Escalabilidad
Big Objects	Almacene y gestione grandes volúmenes de datos en la plataforma.		X
Escáner de código	Explore código Apex para problemas de desempeño.	X
Índices personalizados	Mejore el desempeño de las consultas con índices personalizados.		X
Eliminación de datos	Elimine datos innecesarios para mejorar el desempeño.	X	X
Divisiones	Particione datos para limitar conteos de registros en consultas y reportes.		X
Prueba de escala	Pruebe el desempeño del sistema e interprete los resultados. Antes de implementar en producción, para validar la capacidad de ampliación y el desempeño, imule cargas de trabajo de API e interfaz de usuario a gran escala utilizando secuencias de comandos de Playwright o JMeter.	X	X
Centro de escala	Obtenga perspectivas de autoservicio y en tiempo real sobre el desempeño del sistema. Encuentre transacciones de larga duración, puntos críticos de excepciones y cuellos de botella de rendimiento. Diagnostique problemas de escala más temprano en su ciclo de desarrollo.	X	X
ApexGuru	Utilice esta función basada en GenAI en Scale Center para detectar Apex, SOQL y probar antipatrones de clase en tiempo de ejecución. A través de la integración de ApexGuru con Salesforce Code Analyzer, obtenga recomendaciones con tecnología de IA y soluciones en línea en el flujo de trabajo de desarrollo. Utilice esas recomendaciones y soluciones para resolver puntos críticos y mejorar la selectividad de consultas, la masificación, el uso de caché y la calidad de las pruebas.	X	X
Analizador de código de Salesforce	Escanee código con IDE, CLI o CI/CD para asegurarse de que se ajusta a las mejores prácticas. A través de la integración de Salesforce Code Analyzer con ApexGuru, obtenga perspectivas acerca de antipatrones de desempeño directamente en el flujo de trabajo del desarrollador.	X
Red Salesforce Edge	Mejore los tiempos de descarga y la experiencia de usuario enrutando su Mi dominio a través de Salesforce Edge Network.	X
Tablas delgadas	Evite uniones en tablas que tienen campos utilizados frecuentemente.		X
Proactive Monitoring	Monitoree continuamente anomalías en el crecimiento de registros, el sesgo de propiedad y las regresiones de desempeño. Alerta sobre problemas de escala antes de que se vuelvan críticos.	X	X

## Recursos de Salesforce para fiabilidad

Recurso	Descripción	Disponibilidad	Desempeño	Escalabilidad
Los retos de escalada cuestan millones: así es cómo preparar su negocio para el futuro	Descubra cómo la implementación de la capacidad de ampliación lleva al crecimiento sostenible y al éxito a largo plazo.		X	X
Crear e implementar aplicaciones ampliables utilizando Scale Center	Comprenda cómo evaluar y resolver de forma proactiva problemas de desempeño en sus implementaciones de Salesforce.
Analizar el desempeño y ampliar puntos de acceso en aplicaciones complejas de Salesforce	Solucione problemas de desempeño y capacidad de ampliación en su organización.		X	X
Su aplicación no debería entrar en pánico en el tráfico en horas punta: a continuación le mostramos cómo prepararse	Aprenda cuatro pasos clave para realizar pruebas de escala con éxito.
El motor de IA de ApexGuru explicado	Aprenda cómo ApexGuru utiliza modelos entrenados personalizados, telemetría de organización del mundo real y filtrado inteligente para entregar perspectivas precisas, contextuales y con capacidad de acción.		X	X
Optimizar su Apex para aplicaciones y Agentforce con ApexGuru	Aprenda cómo ApexGuru ayuda a los desarrolladores a detectar y solucionar antipatrones de desempeño, incluyendo SOQL, DML, depuración e ineficiencias de prueba. Utilice ApexGuru como un entrenador con tecnología de IA para el desarrollo ampliable de sus aplicaciones y su implementación de Agentforce.		X	X
ApexGuru Antipatterns	Aprenda de la biblioteca oficial de antipatrones detectados por ApexGuru, que se actualiza para cada versión principal de Salesforce.		X	X
Mejores prácticas para implementaciones con grandes volúmenes de datos	Comprenda la repercusión de los procesos de grandes volúmenes de datos.			X
Consideraciones sobre Salesforce Edge Network	Averigüe cómo preparar su organización para utilizar Salesforce Edge Network.		X
Plantilla de estándares de diseño	Cree estándares de diseño para su organización.	X	X	X
Consideraciones sobre el diseño de modelos de datos	Optimice modelos de datos para la escala y el mantenimiento.		X	X
Diseño del acceso a registros para Enterprise Scale	Optimice el desempeño del control de acceso a través de la configuración.			X
Infraestructura para sistemas con grandes volúmenes de datos	Obtenga información acerca de funciones que admiten el desempeño del sistema para implementaciones con grandes volúmenes de datos.			X
Recursos de aprendizaje para Gestión por lotes	Obtenga información acerca de Gestión por lotes.		X	X
Optimización del desempeño Lightning Experience	Mejore Lightning Experience en su organización para ayudar sus usuarios a trabajar más rápido.		X
Gestionar el sesgo de búsqueda en Salesforce para evitar excepciones de bloqueo de registros	Comprenda cómo minimizar los efectos de los sesgos de búsqueda.		X	X
Mejores prácticas de SOQL y SOSL	Siga las mejores prácticas de SOQL y SOSL para implementaciones con grandes volúmenes de datos.		X	X
Herramientas para alineaciones a gran escala	Planifique y ejecute realineaciones de forma efectiva.			X
Uso de Mashups	Mantenga grandes conjuntos de datos en una aplicación diferente.		X	X

## Dinos lo que piensas Ayúdenos a mantener Salesforce Well-Architected relevante para usted; realice nuestra [encuesta](https://sfdc.co/bxNtvh) para proporcionar comentarios sobre este contenido e indicarnos qué le gustaría ver a continuación. > Lea sobre nuestras programaciones de actualizaciones [aquí](/docs/architect/es-mx/well-architected/guide/contributors). ## Introducción Los sistemas demuestran comportamientos atractivos facilitando a las personas el acceso y el uso de aplicaciones, haciendo que los usuarios sientan que están realizando más trabajo de alta calidad y haciendo que las personas deseen utilizar aplicaciones en el sistema. La entrega de comportamiento atractivo importa al negocio porque se correlaciona directamente con la adopción del usuario, así como la satisfacción general del trabajador y el cliente. Los comportamientos de implicación también ayudan a reducir las solicitudes de asistencia y pueden ayudar a elevar la calidad de las solicitudes de funciones de los usuarios. Uno de los retos de la creación de comportamiento atractivo es que es difícil medir solo por mediciones objetivas. En su lugar, se mide por las experiencias subjetivas de los usuarios; los usuarios sienten que las aplicaciones atractivas proporcionan un valor genuino. Las aplicaciones atractivas son [accesibles](/docs/architect/es-mx/well-architected/guide/compliant#accesibilidad), no intrusivas y fáciles de comprender. Requieren una cantidad mínima de incorporación y capacitación. Además, utilizan métodos claros para evitar de forma proactiva errores de usuario. Otro reto es que los objetivos de implicación a menudo variarán con los diferentes tipos de interacciones de usuario en su sistema. Por ejemplo, puede tener un conjunto de objetivos para usuarios internos que están gestionando casos y otro para usuarios externos que están enviando información a través de un formulario en su sitio web. Para diseñar sistemas de implicación, debe considerar cuidadosamente el tipo de implicación que está intentando crear y por qué los usuarios querrían implicarse antes de empezar a ensamblar funciones y páginas. Asociarse con diseñadores de experiencia de usuario (UX) le ayudará a tomar decisiones mucho más efectivas cuando se trata de entregar aplicaciones atractivas. Desde una perspectiva arquitectónica, la adopción y retención de usuarios son componentes cruciales de un sistema saludable. Las arquitecturas implicadas reducen la probabilidad de Problemas de calidad de datos causados por usuarios que se apresuran a través de procesos u omiten pasos para evitar tener que emplear tiempo en un sistema que no disfrutan utilizando. Para sistemas externos, una arquitectura atractiva puede aumentar los ingresos y la retención de clientes ya que los clientes con los que es más fácil trabajar en sus sistemas eligen hacer más negocios con su organización. Puede crear aplicaciones más atractivas centrándose en entregar experiencias simplificadas y útiles. ## Simplificado Las aplicaciones simplificadas son fáciles de navegar, presentan información y tareas de entrada de datos claramente y se adaptan para ajustarse a varios factores de forma. Las aplicaciones simplificadas también cuentan con patrones de experiencia a los que los usuarios se han acostumbrado en otras aplicaciones utilizadas habitualmente. Por ejemplo, la mayoría de los navegadores web presentan “abrir en nueva ficha” como la opción principal cuando los usuarios hacen clic con el botón derecho del ratón en un vínculo. Una aplicación simplificada que contiene fichas seguirá el mismo patrón. Las repercusiones de experiencias de aplicación ineficientes pueden ir mucho más allá de una aplicación individual. Las malas experiencias de aplicación erosionan la Trust de los usuarios. A medida que más tipos de aplicaciones críticas para el negocio y de cara al cliente pasan a canales digitales, esto puede costar a las compañías la fidelidad de partes interesadas clave. Puede simplificar mejor sus aplicaciones siendo intencionado en el enfoque de la complejidad de la aplicación, el diseño de formularios y los factores de forma. ### Complejidad de aplicación Minimizar la complejidad de la aplicación significa que los usuarios solo ven elementos de menú, fichas y controles de navegación relevantes. Necesitará crear asignaciones entre grupos de usuarios, permisos de usuario y la experiencia de aplicación correcta. Utilice estas asignaciones para comprender qué experiencia de aplicación presentar a un usuario concreto y luego asegúrese de que su aplicación tiene los controles lógicos necesarios para entregar esa experiencia. Las aplicaciones que presentan a los usuarios demasiada complejidad pueden causar una variedad de experiencias deficientes: - Los usuarios ven con frecuencia fichas innecesarias o irrelevantes, navegan a pantallas en blanco y encuentran vínculos desactivados o bloqueados. - Las instrucciones innecesarias o inútiles como "ignorar esta ficha si su función es X..." aparecen en materiales de capacitación y habilitación. - Los menús de navegación abarrotados obligan a los usuarios a emplear tiempo adicional en localizar los elementos que necesitan para realizar el trabajo. Estas experiencias deficientes conducen a bajos índices de adopción y niveles de satisfacción. Tenga en cuenta lo siguiente cuando determine el nivel correcto de complejidad de la aplicación: - Organice menús, fichas y otros controles de navegación basándose en la prioridad del trabajo que necesitan realizar los usuarios. - Evite introducir nuevos comportamientos que un usuario debe aprender únicamente para poder utilizar su aplicación. - No elimine el acceso a funciones que permiten a los usuarios personalizar aspectos de su interfaz de usuario. - Utilice conjuntos de permisos para proporcionar opciones de navegación ampliadas o reducidas. - Simplifique las [asignaciones de activación](https://help.salesforce.com/s/articleView?id=sf.lightning_page_getting_into_salesforce1.htm) de páginas Lightning. Minimice el número de páginas Lightning activas por aplicación. Utilice formularios dinámicos, conjuntos de permisos y representación condicional para agregar elementos a páginas Lightning en su aplicación. Haga esto en vez de mantener varias páginas Lightning, activadas y asignadas por perfil. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/engaging#patrones-y-antipatrones-de-aplicaciones-simplificados) a continuación muestra el aspecto de la gestión de la complejidad de aplicaciones adecuada (y deficiente) en una organización de Salesforce. Puede utilizarlos para validar o mejorar sus diseños de aplicación. Para obtener más información acerca de herramientas de Salesforce que pueden ayudarle a gestionar la complejidad de las aplicaciones, consulte [Herramientas relevantes para](/docs/architect/es-mx/well-architected/guide/engaging#herramientas-relevantes-para-la-implicación) la implicación. ### Formularios Los formularios simplificados organizan la información en secuencias lógicas, admiten la entrada rápida de datos y minimizan los pasos requeridos. También permiten mensajes de validación de datos del lado del cliente [útiles](/docs/architect/es-mx/well-architected/guide/engaging#útil) y eliminan ciclos de envío de formularios repetidos. Tenga en cuenta lo siguiente al diseñar formularios: - **Agrupe campos relacionados**. Agrupe campos relacionados con el mismo paso en un proceso o una tarea de entrada de datos. Elimine campos que no son directamente relevantes para la tarea en cuestión. - **Ponga la entrada y validación de datos temprano**. Los campos que requieren que los usuarios ingresen datos deben aparecer antes en sus formularios. Es una mejor práctica aflorar problemas con formato de datos o datos que faltan a nivel de campo y lo más rápido posible (es decir, antes de que un usuario intente navegar al siguiente paso o enviar el formulario). Además, evite mostrar errores a nivel de campo antes de que los usuarios tengan la oportunidad de ingresar datos en los campos. - **Minimice tareas de entrada** de datos. Rellene o complete automáticamente tantos campos como sea posible, para minimizar los errores de entrada de datos y mejorar la eficiencia. Solo solicite a los usuarios ingresar datos esenciales o críticos. Elimine cualquier entrada de datos que no sea relevante para el proceso de negocio en cuestión. Utilice listas de selección en vez de campos de texto de formato libre donde sea posible para aplicar la selección de opciones válidas y reducir variaciones de la misma respuesta. - **Minimice los envíos al servidor**. No haga que los formularios de múltiples pasos envíen datos al servidor varias veces. Asegúrese de que todos los componentes [LWC](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.apex_result_caching) o [Aura](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/controllers_server_storable_actions.htm) personalizados utilizan caché del lado del cliente para gestionar acciones de navegación o paginación. (Salesforce Lightning Experience y la aplicación móvil Salesforce utilizan caché del lado del cliente de forma predeterminada.) Diseñe formularios de modo que los usuarios envíen datos al servidor solo una vez. Valide entradas de usuario en el lado del cliente antes de enviar formularios. Esto minimizará los envíos de usuarios no intencionados, evitará que las transacciones duplicadas o sucias consuman ancho de banda en el backend y le ayudará a diseñar para una mejor [gestión de datos](/docs/architect/es-mx/well-architected/guide/automated#gestión-de-datos). - **Gestionar estado de formulario**. El almacenamiento en caché del lado del cliente no solo ayuda con comportamientos como la navegación y la paginación, sino que también ayuda a minimizar la pérdida de datos de problemas de conectividad intermitentes. La gestión efectiva del estado también significa que las aplicaciones pueden orquestar adecuadamente el envío de datos al servidor y evitar transacciones duplicadas, junto con la presentación de mensajes relevantes y oportunos a los usuarios basándose en el estado de las acciones del lado del servidor. Los formularios simplificados envían operaciones de datos solo una vez y no requieren que los usuarios esperen que finalicen las operaciones de larga ejecución en el servidor. - **Siga estándares de accesibilidad**. Para maximizar la audiencia de sus aplicaciones y ayudar a garantizar que incluyen a todos sus clientes, aplique estándares de [accesibilidad](/docs/architect/es-mx/well-architected/guide/compliant#accesibilidad) en sus diseños de formularios. Los formularios simplificados ayudan a aumentar la [integridad de datos](/docs/architect/es-mx/well-architected/guide/automated#integridad-de-datos) en sus aplicaciones y cuán [útiles](/docs/architect/es-mx/well-architected/guide/engaging#útil) son sus aplicaciones para los usuarios. También pueden reducir los tickets y las solicitudes de asistencia, ya que los usuarios pueden solucionar mejor los errores y comprender claramente el estado de sus envíos de formularios. Además, los formularios simplificados permiten un ingreso de datos rápido y eficiente, y garantizan que los usuarios no tengan que esperar a que se completen procesos de ejecución más larga para poder realizar más trabajo. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/engaging#patrones-y-antipatrones-de-aplicaciones-simplificados) a continuación muestra el aspecto adecuado (y deficiente) del diseño de formularios en una organización de Salesforce. Puede utilizarlos para validar o mejorar sus diseños de formulario. Para obtener más información acerca de herramientas de Salesforce que pueden ayudarle a crear formularios más simplificados, consulte [Herramientas relevantes para implicarse](/docs/architect/es-mx/well-architected/guide/engaging#herramientas-relevantes-para-la-implicación). Para obtener directrices más específicas sobre la selección de la herramienta de formulario correcta para su caso de uso, consulte la Guía de decisiones del [arquitecto para crear formularios con Salesforce](/docs/architect/es-mx/decision-guides/guide/build-forms#conclusiones-clave). ### Factor de forma Las aplicaciones atractivas se adaptan elegantemente a diferentes dispositivos y tipos de interacción, o factores de forma. Dependiendo del tipo de dispositivo, los diferentes tipos de interacciones de usuario serán más fáciles (o más difíciles) y la capacidad de lectura para formularios y campos cambiará. Recuerde que además de las dimensiones de la pantalla, el factor de forma también hace referencia al modo en que sus usuarios interactúan con la pantalla. Un número creciente de dispositivos ahora tiene pantallas táctiles y algunos usuarios también pueden utilizar dispositivos especiales para [la accesibilidad](/docs/architect/es-mx/well-architected/guide/compliant#accesibilidad). Asegúrese de tener en cuenta estos factores al diseñar formularios. No tener en cuenta las variaciones de factores de forma puede provocar una variedad de problemas, incluyendo: - Mala calidad de los datos - Interfaces de aplicación inutilizables - Más sesiones de solución de problemas o “pedido en nombre de” para agentes de asistencia - Adopción deficiente de usuarios, bajo número de usuarios activos y altas tasas de “abandono” de aplicaciones Para diseñar la interoperabilidad entre factores de forma en sus aplicaciones de Salesforce, considere lo siguiente: - **Identifique factores de forma admitidos para cada aplicación**. - **Identifique métodos de entrada y las necesidades de accesibilidad de sus usuarios**. Consulte [Accesibilidad](/docs/architect/es-mx/well-architected/guide/compliant#accesibilidad) para obtener más información. - **Utilice [funciones estándar](/docs/architect/es-mx/well-architected/guide/intentional#estándar-frente-a-funciones-personalizadas) para proporcionar experiencias adaptativas entre dispositivos siempre que sea posible**. - Las [plantillas Lightning Page](https://help.salesforce.com/s/articleView?id=sf.lightning_page_templates.htm&type=5) proporcionadas por Salesforce admiten diferentes factores de forma de forma predeterminada. Si elige desarrollar plantillas de página Lightning personalizadas con Aura, los desarrolladores tendrán que incorporar información de factores de forma en el archivo de diseño del componente. - Los [componentes de página](https://help.salesforce.com/s/articleView?id=sf.lightning_page_components.htm&type=5) estándar proporcionados por Salesforce gestionan la representación entre factores de forma admitidos por usted. Si crea componentes personalizados con LWC o Aura, los desarrolladores tendrán que gestionar el conocimiento de la anchura (existen diferencias de implementación entre [Aura](https://developer.salesforce.com/docs/atlas.en-us.238.0.lightning.meta/lightning/components_config_for_app_builder_width_aware.htm?q=width) y [LWC](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/use_width_aware)) y declarar la compatibilidad de factores de forma en el archivo de diseño de sus componentes. - **Siga las directrices para simplificar los [formularios en todos](/docs/architect/es-mx/well-architected/guide/engaging#formularios)** los dispositivos. - **Cree planes de prueba (y buenas pruebas) para factores de forma clave**. Idealmente, probaría todos los dispositivos y factores de forma para todas sus aplicaciones. Sin embargo, la configuración de los dispositivos correctos (o simuladores de dispositivos) para pruebas de factores de forma puede ser una inversión significativa. Si sabe que una determinada aplicación o conjunto de aplicaciones tendrá un conjunto significativo de usuarios en dispositivos móviles o tablets, dé prioridad a pruebas precisas para esas aplicaciones en factores de forma de dispositivos móviles y tablets. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/engaging#patrones-y-antipatrones-de-aplicaciones-simplificados) a continuación muestra el aspecto adecuado (y deficiente) de la conciencia de factores de forma en una organización de Salesforce. Puede utilizarlos para validar sus diseños antes de crear o identificar páginas que necesitan refactorizarse. Para obtener más información acerca de herramientas de Salesforce para un diseño de factores de forma efectivo, consulte [Herramientas relevantes para](/docs/architect/es-mx/well-architected/guide/engaging#herramientas-relevantes-para-la-implicación) la implicación. ### Patrones y antipatrones de aplicaciones simplificados La siguiente tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su corrección. ✨ Descubra más patrones para aplicaciones simplificadas en el [Explorador de patrones](/docs/architect/es-mx/well-architected-tools/guide/easy-streamlined) y antipatrones.

	Patrones	Antipatrones
Complejidad de aplicación	En su organización: - Las aplicaciones tienen menos de 10 fichas en la configuración predeterminada proporcionada por el administrador - Ninguna aplicación tiene "Desactivar la personalización de usuario final de elementos de navegación en esta aplicación" establecido como true	En su organización: - Las aplicaciones tienen rutinariamente más de 10 fichas en la configuración predeterminada proporcionada por el administrador - Muchas aplicaciones tienen "Desactivar la personalización de usuario final de elementos de navegación en esta aplicación" establecido como verdadero o el permiso para personalizar elementos de navegación está desactivado en toda la organización
Formularios	En sus aplicaciones: - Los campos siguen agrupaciones lógicas - Los campos de entrada de datos aparecen juntos, en grupos de cinco o menos - Los errores de entrada de datos son claros y aparecen a nivel de campo, antes de que los usuarios naveguen fuera o envíen datos - Los controles de paginación permiten el movimiento entre pasos - El envío de datos se produce una vez - Las etiquetas para acciones y navegación son claras - Se proporcionan comentarios oportunos y visuales para reconocer acciones de usuario como clics de botón - Los botones de navegación (por ejemplo, "ir", "siguiente" y "atrás") se colocan de forma coherente en toda la interfaz de usuario	En sus aplicaciones: - Los campos de entrada de datos no están agrupados lógicamente, requiriendo una gran cantidad de cambios de contexto por parte de los usuarios que rellenan formularios - Los errores de entrada de datos contienen información críptica que solo puede interpretar alguien que comprende el funcionamiento interno del sistema - Los errores de entrada de datos solo aparecen cuando se hace clic en el botón de envío de un formulario - Los pasos y agrupaciones no están claramente definidos, dificultando la navegación - El envío de datos se produce varias veces a lo largo del proceso de entrada de datos - Las etiquetas para acciones y navegación son confusas para usuarios que no están familiarizados con funciones subyacentes del sistema - No se proporciona reconocimiento visual de acciones de usuario - Los botones de navegación aparecen en ubicaciones arbitrarias en la interfaz de usuario
Formularios	En su lógica de formulario: - Los campos se rellenan previamente o se rellenan automáticamente tanto como sea posible - No se requiere a los usuarios esperar que se completen acciones del lado del servidor de larga ejecución - Los componentes personalizados utilizan `cacheable=true` para acciones basadas en servidor que no implican operaciones de datos - Las operaciones de datos se realizan una vez - En LWC, los adaptadores `@wire` gestionan todas las acciones que no implican operaciones de datos	En su lógica de formulario: - Los campos que se pueden rellenar previamente o rellenar automáticamente requieren ingreso manual - Los usuarios tienen que dejar de trabajar durante el proceso de envío para esperar que se completen las acciones del lado del servidor - Conjunto de componentes personalizados `cacheable=false`
Factor de forma	En su organización: - Las plantillas de página Lightning proporcionadas por Salesforce se utilizan para todas o la mayoría de las páginas - Las plantillas de página Lightning personalizadas utilizan `design:supportedFormFactors` y `design:supportedFormFactor` en archivos de diseño de componentes Aura - Los componentes LWC o Aura personalizados disponibles en el Generador de aplicaciones declaran factores de forma compatibles en sus respectivos archivos de diseño e implementan patrones de estilo que tienen en cuenta la anchura	En su organización: - Classic sigue activo - Las plantillas de página Lightning personalizadas no utilizan uniformemente `design:supportedFormFactors` y `design:supportedFormFactor` en archivos de diseño de componentes Aura - Los componentes LWC o Aura personalizados disponibles en el Generador de aplicaciones no declaran coherentemente factores de forma admitidos en sus respectivos archivos de diseño - En componentes LWC o Aura personalizados, el estilo que tiene en cuenta el ancho no está implementado por interfaces proporcionadas por Salesforce - En componentes LWC o Aura personalizados, el estilo para diferentes factores de forma está dirigido puramente por valores de `px` o `%` codificados en CSS
	En escritorio: - Los campos de entrada de datos y los controles de navegación se ajustan a la pantalla y se puede interactuar con ellos según lo previsto - Las páginas de registro y aplicación aparecen correctamente, basándose en reglas de asignación de activación de página	En escritorio: - Los campos de entrada de datos y los controles de navegación no aparecen en sus ubicaciones previstas en la pantalla - Las interacciones con campos de entrada de datos y controles de navegación no coinciden con comportamientos requeridos - La falta de reglas de asignación de activación de página significa que todos los usuarios ven las mismas páginas de registro y aplicación
	En dispositivos móviles y tablets: - Las entradas de datos y los controles de navegación aparecen correctamente - Los usuarios pueden ingresar datos fácilmente - Los menús de navegación móvil, optimizados para factores de forma más pequeños, aparecen - Los formatos compactos aparecen a nivel de registro	En dispositivos móviles y tablets: - Las entradas de datos y los controles de navegación no se representan de forma coherente o correcta - Los usuarios no pueden ingresar datos fácilmente - Los menús de navegación móvil no se distinguen de la navegación de escritorio - Los formatos compactos no están configurados a nivel de registro

## Útil Las aplicaciones útiles permiten a los usuarios sentirse más empoderados y efectivos, con menos distracciones o interrupciones. Las aplicaciones útiles ayudan a mantener la [integridad de datos](/docs/architect/es-mx/well-architected/guide/automated#integridad-de-datos) mitigando errores manuales y proporcionando comentarios a los usuarios cuando y donde los necesitan. Ayudan a los usuarios a comprender en qué acciones necesitan centrarse ahora y después, y proporcionan información relevante para ayudar los usuarios a resolver sus propios problemas con mayor rapidez. Proporcionan un vínculo claro entre las acciones de un usuario y la repercusión o los logros significativos. Puede crear aplicaciones más útiles con tres hábitos clave: notificación y mensajes, directrices en aplicación y reconocimiento y recompensas. ### Notificaciones y mensajes Las notificaciones y los mensajes ayudan a los usuarios a mantenerse informados. Un sistema de notificación y mensajería bien diseñado puede aumentar la implicación y la productividad proporcionando a los usuarios la información que necesitan para tomar decisiones críticas de forma oportuna. Un sistema de notificación y mensajería mal diseñado, uno que presenta mensajes que no son relevantes ni oportunos, tendrá el efecto contrario. Los usuarios internos desactivarán o ignorarán rápidamente las notificaciones, lo que les hará perderse mensajes legítimos que podrían afectar a procesos de negocio esenciales. Los clientes u otros usuarios externos que se cansan de las notificaciones sin sentido pueden decidir dejar de utilizar sus sistemas por completo. Al decidir cómo gestionarán las aplicaciones el envío de notificaciones y mensajes a usuarios, tenga en cuenta lo siguiente: - **Para errores, utilice notificaciones y mensajes como último recurso**. Diseñe la [gestión de errores](/docs/architect/es-mx/well-architected/guide/automated#tratamiento-de-errores) en su sistema con procesamiento back-end que puede corregir ciertos tipos de errores sin intervención humana. Envíe a los usuarios solo mensajes acerca de errores críticos que les impedirán completar tareas. Del mismo modo, envíe a los usuarios de negocio solo mensajes de error cuando haya alguna acción correctiva que puedan (y necesiten) realizar por sí mismos. Los detalles o mensajes de error adicionales pueden estar disponibles a través de reportes o enviarse al personal de asistencia técnica utilizando métodos asíncronos para un seguimiento posterior. - **Seleccione tipos de mensajes en función de la relevancia, la urgencia y la puntualidad**. Los diferentes tipos de mensajes tienen diferentes niveles de comportamiento de bloqueo o interrupción. Los avisos son un tipo de mensaje de “bloqueo”, ya que requieren que los usuarios los reconozcan antes de poder continuar con su trabajo. Al igual que con los mensajes de error, los avisos deben utilizarse con moderación. Las notificaciones de alerta no son [bloqueantes](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/use_toast), pueden tener diferentes comportamientos de persistencia y admitir diferentes tipos de casos de uso de mensajes. Los mensajes menos perturbadores son las [notificaciones en aplicación](https://help.salesforce.com/s/articleView?id=sf.notif_builder.htm&type=5) o los emails. Estos se utilizan mejor para entregar información con la que los usuarios pueden tratar cuando y como elijan. - **Considera lo que tiene que suceder después**. Aunque algunas notificaciones son informativas (como mensajes de operación correcta), otras pueden requerir que los usuarios realicen algún tipo de acción. Al diseñar notificaciones, asegúrese de tener en cuenta no solo la notificación en sí, sino cualquier información adicional que un usuario podría necesitar para realizar acciones. Incluya instrucciones claras o vínculos a donde los usuarios pueden encontrar información adicional o completar pasos de seguimiento en todas las notificaciones con capacidad de acción. - **Céntrese en la legibilidad**. Asegúrese de comunicar claramente el propósito de cada notificación y los siguientes pasos que debe realizar un usuario en respuesta. Los mensajes deben ser comprensibles para usuarios de negocio que no están familiarizados con el funcionamiento interno de los sistemas subyacentes. Al crear mensajes, siga los [estándares de accesibilidad](/docs/architect/es-mx/well-architected/guide/compliant#accesibilidad) y asegúrese de que están localizados para dar asistencia a los usuarios en las regiones donde pueden aparecer. Incluya patrones para cuándo utilizar notificaciones o diferentes tipos de errores en sus [estándares de diseño](/docs/architect/es-mx/well-architected/guide/intentional#estándares-de-diseño) para ayudar a garantizar que los generadores de aplicaciones siguen prácticas coherentes. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/engaging#patrones-y-antipatrones-de-aplicaciones-útiles) a continuación muestra el aspecto adecuado (y deficiente) de las notificaciones y la mensajería en una organización de Salesforce. Puede utilizarlos para validar sus diseños antes de construir o identificar usos que necesitan refactorizarse. Para obtener más información acerca de las herramientas de Salesforce para notificaciones y mensajería, consulte [Herramientas relevantes para implicarse](/docs/architect/es-mx/well-architected/guide/engaging#herramientas-relevantes-para-la-implicación). ### Directrices en aplicación Las directrices en aplicación pueden ser una forma potente de desmitificar flujos de trabajo complejos (aunque debe asegurarse de haberlos [optimizado](/docs/architect/es-mx/well-architected/guide/automated#diseño-de-procesos) primero) o ayudar a incorporar nuevo personal. Puede ser una excelente forma de introducir cambios en los procesos, resaltar nuevas funciones o distribuir la capacitación de forma automatizada y ampliable. Sin embargo, si no se implementa cuidadosamente, las directrices en aplicación pueden utilizarse en exceso. Las alertas o elementos emergentes frecuentes pueden crear una gran cantidad de ruido e interrupciones para los usuarios, lo que lleva a la pérdida de productividad. Las directrices en aplicación también pueden estar infrautilizadas, dando como resultado procesos de gestión de cambios y versiones más engorrosos (especialmente para funciones sencillas). En última instancia, tanto el uso excesivo como el uso insuficiente de directrices en aplicación conducen a una serie de problemas que plantean riesgos para el negocio, incluyendo: - Integridad de datos inferior - Aumento de errores de usuario - Mayores niveles de frustración de los usuarios y menor satisfacción de los usuarios - Menor productividad de usuarios Tenga en cuenta que es posible que desee utilizar directrices en aplicación de forma diferente en diferentes escenarios, ya que la mentalidad de un usuario dictará cuánta orientación es “demasiada” frente a “no suficiente”. Los usuarios que se presentan a un nuevo sistema por primera vez probablemente requerirán mensajería más frecuente que los usuarios que simplemente están aprendiendo sobre una nueva función en un sistema con el que ya están familiarizados. Estas son algunas claves para crear directrices en aplicación efectivas: - **Desarrollar estándares de diseño**. Es importante recordar que la sobreexposición a directrices en aplicación puede provocar que los usuarios comiencen a descartar o ignorar mensajes de forma rutinaria. En este punto, las directrices en aplicación se convierten en una molestia, en vez de un recurso. Defina [estándares de diseño](/docs/architect/es-mx/well-architected/guide/intentional#estándares-de-diseño) para dejar claro cuándo utilizar solicitudes, presentaciones, texto de ayuda a nivel de campo, mensajes de validación, rutas, flujos de pantalla, etc. - **Cree un sistema de prioridades para implementaciones de directrices**. No todos los casos de uso para directrices en aplicación deben implementarse. En su lugar, considere las siguientes preguntas para priorizar. ¿Dónde puede utilizar simplemente mejores nombres de campo, etiquetas más explícitas en botones, mejor [diseño de formularios](/docs/architect/es-mx/well-architected/guide/engaging#formularios) y [optimización de procesos](/docs/architect/es-mx/well-architected/guide/automated#diseño-de-procesos) para crear flujos de trabajo más intuitivos? ¿Dónde puede agregar texto o vínculos más útiles a una ruta? ¿Qué [impacto de costo](/docs/architect/es-mx/resources/guide/kpi-spreadsheet-template) de negocio tendrán las directrices en aplicación? ¿Con qué frecuencia desea entregar mensajes a sus usuarios? Además, asegúrese de que cualquier implementación está incluida en su [hoja de ruta](/docs/architect/es-mx/well-architected/guide/intentional#hoja-de-ruta), de modo que todas las partes interesadas tengan visibilidad. - **Asigne usuarios a directrices en aplicación activas (y propuestas)**. La asignación de usuarios a directrices en aplicación le ayudará a identificar y evitar la “sobrecarga de ayuda” debido a demasiadas directrices en aplicación que aparecen para un usuario. A menudo esto es el resultado de un desarrollo aislado, ya que los equipos piensan demasiado en su caso de uso concreto. Mantener una vista holística de lo que los usuarios estarán expuestos es especialmente crítico para organizaciones de gran tamaño. Incluir implementaciones de directrices en su hoja de ruta también puede ayudar. - **Recopile y utilice comentarios para mejorar**. Revise datos sobre el uso de directrices en aplicación y utilícelos para juzgar la eficacia de implementaciones de directrices en aplicación. Asegúrese de proporcionar formas para que los usuarios también proporcionen comentarios abiertos para ayudar a los generadores de directrices. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/engaging#patrones-y-antipatrones-de-aplicaciones-útiles) a continuación muestra el aspecto de las directrices en aplicación adecuadas (y deficientes) en una organización de Salesforce. Puede utilizarlos para validar diseños antes de construir e identificar implementaciones que necesitan refactorizarse. Para obtener más información acerca de herramientas de Salesforce para directrices en aplicación, consulte [Herramientas relevantes para implicarse](/docs/architect/es-mx/well-architected/guide/engaging#herramientas-relevantes-para-la-implicación). ### Reconocimiento y recompensas La incorporación de reconocimiento y recompensas en una aplicación ayuda a las personas que utilizan esa aplicación a sentirse más conectadas con la repercusión de su trabajo y comprender mejor el valor de sus contribuciones, productividad y desempeño. También es una forma potente de desbloquear la fidelidad y la implicación. No diseñar para el reconocimiento o experiencias de aplicación gratificantes puede contribuir a una variedad de problemas, incluyendo: - Usuarios que tienen dificultades para comprender su progreso o velocidad - Confusión sobre el progreso hacia los objetivos o el trabajo inacabado - Usuarios más improductivos, que no ven una conexión entre sus tareas y la “imagen general” - Tiempo de gestión perdido en la creación de reportes de objetivos manuales de bajo nivel Las experiencias de aplicación gratificantes pueden ser difíciles de diseñar y entregar, porque dependen de la cultura, las políticas y los estándares de la compañía, así como del contexto y las preferencias de los usuarios individuales. Las funciones que pueden ayudar a los usuarios de escritorio a sentir momentos de placer o aprecio pueden convertirse en una irritación para un usuario en dispositivos móviles o un usuario que intenta trabajar desde una oficina en casa ruidosa y ocupada. Es posible que las personas que utilizan una aplicación para trabajar con información privada o altamente confidencial no aprecien la comunicación sobre eventos clave en forma de celebraciones de confeti o insignias. Por el contrario, un equipo de ventas distribuido puede ver dicha ludificación como una experiencia de aplicación apropiadamente gratificante. En última instancia, los patrones de implementación que elija pueden determinarse mejor trabajando con diseñadores de experiencia de usuario (UX) en un equipo. Cuando se trata de arquitectura, es importante identificar cómo y dónde las aplicaciones pueden implementar funciones que ayudan a los usuarios a sentirse reconocidos y recompensados. También es clave comprender cómo y dónde estas funciones podrían hacer que las aplicaciones sean menos [reutilizables](/docs/architect/es-mx/well-architected/guide/composable) o impedir la entrega de [valor de negocio](/docs/architect/es-mx/well-architected/guide/automated#valor-de-negocio). Estas son algunas preguntas a tener en cuenta al evaluar el reconocimiento y las recompensas en aplicaciones de Salesforce: - **¿Cómo y dónde pueden los usuarios ver su propio progreso, así como estadísticas generales del equipo?** Los reportes son importantes, pero a menudo contienen datos de resumen que pueden perder el contexto del trabajo diario. Puede utilizar una herramienta como el generador de aplicaciones Lightning para integrar gráficos o tableros en pantallas de registro en el contexto de una aplicación, ayudando a los usuarios a comprender su repercusión o progreso a medida que realizan sus tareas diarias. - **¿Cómo se deben reconocer los usuarios?** Esto puede variar según las preferencias del equipo o del individuo. En algunos casos, es posible que los supervisores deseen ver mensajes sobre el progreso de los usuarios de modo que puedan compartirse con un grupo más grande. El reconocimiento también puede ser una ventaja adicional para ayudar con la moral de los empleados. Además, en otros casos, los usuarios pueden simplemente preferir ser los únicos notificados sobre su progreso en una tarea o proyecto concreto. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/engaging#patrones-y-antipatrones-de-aplicaciones-útiles) a continuación muestra el aspecto adecuado (y deficiente) del reconocimiento y las recompensas en una organización de Salesforce. Puede utilizarlos para validar diseños antes de construir e identificar implementaciones que necesitan refactorizarse. Para obtener más información acerca de las herramientas de Salesforce para el reconocimiento y las recompensas, consulte [Herramientas relevantes para](/docs/architect/es-mx/well-architected/guide/engaging#herramientas-relevantes-para-la-implicación) la implicación. ### Patrones y antipatrones de aplicaciones útiles La siguiente tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su corrección. ✨ Descubra más patrones para aplicaciones útiles en el [Explorador de patrones](/docs/architect/es-mx/well-architected-tools/guide/easy-helpful) y antipatrones.

	Patrones	Antipatrones
Notificaciones y mensajes	Sus estándares de diseño incluyen: - Casos de uso aprobados para notificaciones, saludos y notificaciones - Patrones de diseño para variantes de saludo y notificaciones - Patrones de diseño para mensajería de error	Si los estándares de diseño están definidos, no solucionan errores y notificaciones
	En su organización: - Las notificaciones son el formato de mensajería predominante - Los mensajes de saludo utilizan variantes - Mensajes de saludo con `modo` establecido como `pegajoso` no existen - Los avisos se utilizan rara vez, si es que se utilizan - Las respuestas generativas siempre identifican orígenes de datos utilizados - Los bots se identifican claramente antes de la primera interacción con los usuarios - Las renuncias de responsabilidad por riesgos asociados con la IA generativa aparecen a los usuarios antes de la primera interacción - Las renuncias de responsabilidad de IA están en un lenguaje claro y comprensible para los usuarios	En su organización: - Los emails son el formato de mensajería predominante - No hay un enfoque coherente para los tipos de mensajes - Los mensajes de saludo no utilizan variantes de forma coherente - Mensajes de saludo con el `modo` establecido como `pegajoso` existen - Los avisos se utilizan ad hoc - Las respuestas generativas no identifican orígenes de datos utilizados - Los bots no se identifican claramente antes de la primera interacción con los usuarios - No aparecen renuncias de responsabilidad por riesgos de IA generativa a los usuarios - Las renuncias de responsabilidad de IA no están en un lenguaje claro y comprensible para los usuarios
	En sus aplicaciones: - No se envían respuestas generativas directamente a usuarios finales sin puntos de implicación humana	En sus aplicaciones: - Las respuestas generativas se envían directamente a usuarios finales sin puntos de implicación humana
Consulte también: Tratamiento de errores
Directrices en aplicación	Sus estándares de diseño y documentación incluyen: - Casos de uso aprobados para directrices en aplicación - Patrones de diseño para solicitudes y presentaciones - Una matriz clara de usuarios, aplicaciones y directrices en aplicación activas	Si existen estándares de diseño y documentación, estos: - No tratar directrices en aplicación - No incluir una matriz clara mostrando usuarios, aplicaciones, directrices en aplicación activas
Directrices en aplicación	En su organización: - La configuración para "Demora entre directrices en aplicación" utiliza el valor predeterminado o un valor personalizado que es superior al periodo predeterminado (24 horas) proporcionado por Salesforce - Ninguna aplicación tiene más de una presentación activa - Ninguna presentación tiene un parámetro "Tiempos para mostrar" que sea superior a 10 - No se activan solicitudes para "Cualquier página, cualquier aplicación" o "Esta página, cualquier aplicación"	En su organización: - La configuración para "Demora entre directrices en aplicación" se establece en un periodo que es más corto que el periodo predeterminado (24 horas) proporcionado por Salesforce - Las aplicaciones tienen más de una presentación activa - Muchas presentaciones tienen un parámetro "Tiempos para mostrar" que es superior a 10 (y algunas tienen el valor máximo de 30) - Las solicitudes se activan ad hoc, muchas con la configuración "Cualquier página, cualquier aplicación" o "Esta página, cualquier aplicación"
Reconocimiento y recompensas	En su organización: - Las aplicaciones utilizan análisis integrados para mostrar a los usuarios estadísticas de productividad y progreso de objetivos relevantes - Las celebraciones de rutas solo se activan con el consentimiento del usuario - Las notificaciones y la mensajería incluyen el reconocimiento de usuarios y reflejan las preferencias de los usuarios en el diseño de quién recibe notificaciones y qué desencadena notificaciones	En su organización: - Analytics relacionados con el progreso de objetivos y estadísticas de productividad solo están disponibles en reportes o tableros de gestor - Las celebraciones de rutas están activadas sin comprobar el consentimiento del usuario - Las notificaciones y la mensajería no incluyen ningún tipo de reconocimiento de usuario o no reflejan las preferencias de los usuarios y se sienten ruidosas o confusas

## Herramientas relevantes para la implicación

Herramienta	Descripción	Simplificado	Útil
Activar su página de aplicación Lightning	Gestionar la disponibilidad, los nombres, la visibilidad y el posicionamiento de las páginas	X
Tableros de adopción	Revisar el historial de inicios de sesión, la adopción de funciones y la productividad	X	X
Alerta	Persistir alertas sobre sesiones y mostrarlas sin inicio de usuario		X
Caché del lado del cliente de resultados de métodos Apex	Evaluar el desempeño con datos del lado del cliente en caché	X
Formularios dinámicos	Solo mostrar campos obligatorios y secciones de página a usuarios	X
Perspectivas de implicación	Monitorear la actividad de usuarios recientes y realizar acciones según sea necesario	X	X
Directrices en aplicación	Utilizar solicitudes y presentaciones para capacitación e incorporación		X
Rutas de aprendizaje	Personalizar experiencias de aprendizaje de usuarios		X
Generador de aplicaciones Lightning	Crear páginas Lightning y móviles personalizadas sin código	X
Servicio de datos Lightning	Almacenar en caché y compartir datos entre componentes	X
Validador del sistema Lightning Design para VS Code	Validar el marcado con directrices SLDS	X	X
Plantillas de páginas Lightning	Crear páginas Lightning para diferentes factores de forma	X
Filtros de búsqueda	Filtrar valores para búsqueda, principal-detalle y relaciones jerárquicas	X
Gestionar varias divisas	Utilizar varias divisas en transacciones		X
Mensajería	Enviar mensajes SMS, Facebook Messenger o WhatsApp		X
Mobile Publisher	Crear versiones móviles de aplicaciones Lightning y sitios de Experience Cloud	X
Componentes listos para dispositivos móviles	Construir componentes que tengan un buen desempeño entre experiencias móviles	X
Sitios multilingües	Crear diferentes versiones de idioma de su sitio	X	X
Generador de notificaciones	Crear notificaciones personalizadas para presentar información		X
Ruta	Guíe a los usuarios por los procesos de negocio y celebre el éxito	X	X
Caché de plataforma	Mejorar el desempeño y la fiabilidad al almacenar datos en caché	X
Vista previa de páginas de aplicaciones móviles en Lightning App Builder	Vista previa de páginas de aplicación y registro en un dispositivo móvil	X
Solicitud	Alertar a los usuarios de problemas y actualizaciones relacionados con el sistema		X
Insignias de reconocimiento	Reconocer y celebrar logros de usuarios		X
Reconocimiento con WDC	Aprobar habilidades y dar las gracias		X
Tipos de registro	Personalizar procesos de negocio, valores de lista de selección y formatos de página	X	X
Descripción general de reputación	Reconocer la participación y el intercambio Knowledge		X
Reglas de restricción	Evitar que los usuarios accedan a registros que pueden contener datos innecesarios	X
Componentes de página estándar	Comprender los componentes estándar de Salesforce Lightning	X
Traducciones	Gestionar traducciones para usuarios globales	X	X
Reglas de validación	Verificar que los datos cumplen los estándares especificados antes de guardar	X

## Recursos relevantes para la implicación

Recurso	Descripción	Simplificado	Útil
Guía del arquitecto para la creación de formularios	Evaluar consideraciones de diseño de formularios y seleccionar la mejor herramienta	X
Configurar su componente para diferentes factores de forma	Configurar componentes para representar en escritorios y teléfonos	X
Personalizar contenido de ayuda	Adaptar contenido de ayuda a su implementación exclusiva		X
Valores de campo predeterminados	Definir valores de campo predeterminados, dinámicos o estáticos	X
Directrices de diseño	Crear interfaces de usuario coherentes con mejores prácticas	X	X
Plantilla de estándares de diseño	Crear estándares de diseño para su organización	X	X
Diseñar habilidades de prueba (Trailhead)	Planificar métodos para validar y probar diseños	X	X
Directrices de comentarios en aplicación	Revisar directrices para recopilar comentarios desde su sistema	X	X
Biblioteca estática Android del Sistema Lightning Design	Crear aplicaciones Android nativas con el aspecto de páginas Lightning	X
Lightning Design System iOS Static Library	Crear aplicaciones iOS nativas con el aspecto de páginas Lightning	X
Directrices de mensajería	Comunicar información relevante y crear momentos de placer		X
Tipos de mensajería	Comprender los diferentes tipos de mensajería basándose en la interacción de usuarios		X
Directrices de navegación	Ayudar los usuarios a moverse entre páginas y situarse en una aplicación	X
Pruebas de accesibilidad web (Trailhead)	Utilizar pruebas automatizadas y manuales para garantizar la accesibilidad	X	X
Directrices de implicación de usuarios	Revisar directrices para la incorporación, adopción, asistencia y aprendizaje	X	X

## Dinos lo que piensas Ayúdenos a mantener Salesforce Well-Architected relevante para usted; realice nuestra [encuesta](https://sfdc.co/bxNtvh) para proporcionar comentarios sobre este contenido e indicarnos qué le gustaría ver a continuación. > Lea sobre nuestras programaciones de actualizaciones [aquí](/docs/architect/es-mx/well-architected/guide/contributors). ## Introducción Las soluciones intencionadas entregan valor de negocio inmediatamente y a lo largo del tiempo. Las arquitecturas intencionales se planifican y se entregan de forma estratégica, se pueden mantener de forma efectiva y son fáciles de leer y comprender para los humanos. Las funciones y soluciones se priorizan y se entregan de formas transparentes para las partes interesadas de negocio y tecnología por igual. Las opciones de ingeniería crean implementaciones que son fáciles de trabajar para los equipos de entrega y mantenimiento, sin funciones o complicaciones agregadas. Las arquitecturas intencionales son más fáciles de poseer, mantener y evolucionar con el negocio porque siguen patrones de implementación claros y coherentes. Los constructores pueden interpretar e implementar diseños para nuevas funciones, y los equipos de mantenimiento pueden comprender la documentación de lo que se implementó. Puede crear sistemas más intencionados centrándose en tres áreas clave: estrategia, capacidad de mantenimiento y capacidad de lectura. ## Estrategia Estrategia en arquitectura significa que los sistemas se planifican y entregan cuidadosamente. Significa que los equipos de entrega y mantenimiento tienen una visión clara del trabajo que se debe realizar hoy y en el futuro, y todos están alineados en torno al “por qué” del trabajo que se debe realizar. Significa que las solicitudes urgentes se pueden procesar de forma efectiva y eficiente, y las partes interesadas pueden comprender claramente la repercusión y las ventajas de las solicitudes. Puede construir una estrategia más clara en su arquitectura centrándose en la priorización, la hoja de ruta y la gobernanza. ### Priorización Priorización significa planificar el orden y el ámbito del trabajo que entregará. La priorización implica comprender la repercusión real de los productos en el negocio, evaluar esas repercusiones frente a otras solicitudes de trabajo y la hoja de ruta general para su producto o programa. Una forma de evaluar la repercusión de un elemento de trabajo concreto es ver el costo o beneficio real para el negocio. Una vez que haya identificado los [KPI](/docs/architect/es-mx/well-architected/guide/automated#kpis) para la automatización, puede utilizar una [hoja de cálculo](/docs/architect/es-mx/resources/guide/kpi-spreadsheet-template) de impacto de negocio para evaluar el costo o beneficio general de la implementación. Estos cálculos pueden ayudarle a obtener la alineación y la aceptación de sus partes interesadas acerca de qué automatizaciones crear y en qué orden. También pueden ayudarle a identificar automatizaciones para posponer o evitar. Para automatizaciones, consulte [Diseño de procesos](/docs/architect/es-mx/well-architected/guide/automated#diseño-de-procesos) para obtener más información acerca de la identificación de trabajo efectivo. Establecer un marco de prioridades para la entrega también le ayudará a usted y a sus equipos de mantenimiento a gestionar las expectativas de los usuarios y permanecer alineados con su hoja de ruta. Algunas consideraciones que puede utilizar para la priorización incluyen: - Repercusión de negocio (costo/beneficio) del producto - Cantidad de nuevo trabajo requerido para el producto - Cantidad de trabajo requerido para mantener el producto La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/intentional#patrones-de-estrategia-y-antipatrones) a continuación muestra el aspecto de la priorización apropiada (y deficiente) cuando se trata de trabajo de Salesforce. Puede utilizarlos para validar sus planes de implementación o identificar dónde necesita identificar mejor las prioridades antes de construir. Para obtener más información acerca de las herramientas disponibles en Salesforce para obtener ayuda con la priorización, consulte [Herramientas relevantes para intencional](/docs/architect/es-mx/well-architected/guide/intentional#herramientas-relevantes-para-intencional). ### Hoja de ruta Una hoja de ruta es una vista priorizada, validada y bien definida de lo que se debe hacer. Las hojas de ruta efectivas proporcionan una imagen clara de la repercusión de negocio y la repercusión tecnológica del trabajo futuro. Implicar a sus partes interesadas de negocio y técnicas es una parte clave de la hoja de ruta. Las hojas de ruta le permiten obtener comentarios y aceptación sobre el enfoque y los resultados antes de que comience cualquier trabajo. En última instancia, las hojas de ruta alinean a todas las partes interesadas sobre el “por qué” del trabajo por delante. Si su equipo utiliza un retraso, es importante comprender que su hoja de ruta no es un resumen o una lista de los elementos en el retraso. La relación es la opuesta: Los elementos solo se incluyen en el retraso si se pueden vincular de forma clara y creíble a un producto en su hoja de ruta. Las hojas de ruta de alta calidad, creadas con la participación de las partes interesadas, proporcionan a los equipos de entrega y mantenimiento una visión clara de en qué deben centrarse y cómo deben priorizar las solicitudes, facilitando la tarea de ordenar las solicitudes en conflicto y gestionar las expectativas de las partes interesadas. Una hoja de ruta deficiente o inexistente lleva a: - Falta de claridad sobre cuándo estarán disponibles nuevas funciones y características - Prioridades en conflicto entre las partes interesadas - Una desconexión entre las soluciones que se están entregando y la visión organizativa general - Dificultad para comprender qué trabajo está en curso - Cargas de trabajo desiguales entre equipos - Falta de visibilidad de las relaciones y dependencias entre elementos de trabajo - Implementaciones estancadas, debido a dependencias mal gestionadas Las partes interesadas a menudo necesitan información que se ajuste a sus funciones para poder tomar decisiones. La creación de hojas de ruta efectivas requiere una comprensión clara de su audiencia y el tipo de información que necesita. Las hojas de ruta se categorizan en dos estilos para dar cobertura a audiencias de negocio y técnicas. Cada estilo contiene dos niveles de granularidad para admitir diferentes tipos de información. Las hojas de ruta de negocio ayudan a las partes interesadas a planificar cambios organizativos, capitalizar oportunidades de crecimiento y permanecer alineadas con objetivos corporativos. Las hojas de ruta de negocio también proporcionan una forma de garantizar que el gasto de TI se alinea con la visión de negocio general. - Cree una hoja de ruta de funciones de negocio para mostrar a las partes interesadas ejecutivas las funciones que se activarán. Este tipo de hoja de ruta contiene detalles de alto nivel sobre las funciones en sí mismas y cómo se alinean con los objetivos de negocio, como el aumento de la eficiencia operativa o el lanzamiento de una nueva línea de productos. - Cree una hoja de ruta de funciones de negocio para desglosar una función específica y mostrar sus funciones y funciones de asistencia cuando necesite ayudar a las partes interesadas de negocio con la planificación de recursos, el presupuesto y la gestión de cambios. Las hojas de ruta de tecnología ayudan a las partes interesadas técnicas con la planificación de presupuestos y asignaciones de recursos. También ayudan a los equipos de implementación a comprender dónde se ajustan sus proyectos como parte de una imagen general más amplia e identificar cualquier dependencia entre equipos. - Cree una hoja de ruta del sistema de tecnología para mostrar los sistemas específicos que se implementarán, junto con cualquier dependencia a nivel del sistema. Este tipo de hoja de ruta muestra información de sistema de alto nivel y la alineación entre sistemas y funciones de negocio. - Cree una hoja de ruta de componente de tecnología para desglosar los componentes específicos de un sistema que se implementará para ayudar con la planificación de recursos y los requisitos de habilitación. Este tipo de hoja de ruta muestra información a nivel de componente y requisitos de implementación (por ejemplo, desarrollo declarativo, procódigo, etc.). Asegúrese de que sus hojas de ruta contienen cronologías realistas. Un error común es incluir solo la cantidad de tiempo que se tardará en implementar un sistema sin tener en cuenta también la cantidad de tiempo que se tardará en completar las actividades relacionadas. Esto puede dar como resultado una asignación excesiva de miembros del equipo de implementación y retrasos más largos de lo previsto. Al crear una hoja de ruta, tenga en cuenta el tiempo que tardará en completar lo siguiente: - Documentación de todas las funciones nuevas y actualizadas - Mantenimiento de funciones existentes necesarias para dar cobertura a nuevas funciones - Actualizaciones en sistemas relacionados requeridas para admitir integraciones - Asistencia elevada de los equipos de proyectos inmediatamente después del lanzamiento - Pruebas, capacitación y gestión de cambios Las hojas de ruta de negocio y tecnología que están bien alineadas comunican una visión holística de cuándo se pondrán en marcha las funciones y qué tecnología hay detrás de ellas. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/intentional#patrones-de-estrategia-y-antipatrones) a continuación muestra el aspecto de las hojas de ruta apropiadas (y deficientes) para una organización de Salesforce. Puede utilizarlos para validar o mejorar su estrategia de hoja de ruta. Para obtener más información acerca de herramientas de Salesforce que pueden ayudarle con la hoja de ruta, consulte [Herramientas relevantes para intencionado](/docs/architect/es-mx/well-architected/guide/intentional#herramientas-relevantes-para-intencional). ### Gobernanza La gobernanza es la estructura que utiliza para gestionar la priorización, la toma de decisiones y la gestión de cambios con sus partes interesadas. La gobernanza deja claro cómo se toman y se comunican las decisiones. Proporciona formas coherentes para que los comentarios y las solicitudes entren en el proceso de toma de decisiones, y para que todas las partes interesadas comprendan el estado del trabajo de mantenimiento y desarrollo. La gobernanza ayuda a que los procesos de gestión de versiones sean claros y coherentes, y ayuda a todos los miembros del equipo a comprender sus funciones y responsabilidades. Sin una gobernanza apropiada, los equipos experimentarán una variedad de problemas, incluyendo: - Las solicitudes de funciones y funciones superpuestas llegan ad hoc - Los equipos de implementación priorizan esfuerzos "más sencillos" o solicitudes de partes interesadas más influyentes, sin tener en cuenta adecuadamente el valor de negocio, las compensaciones o los objetivos organizativos generales - Falta de procesos de aprobación y revisión coherentes - Calidad y cadencias de versión incoherentes - Altos índices de defectos, sobrescrituras, conflictos y trabajo redundante en esfuerzos de desarrollo Quizás la señal más clara de que un sistema no tiene una regulación efectiva es la lentitud y la incomodidad de las versiones. Es importante reconocer que el tamaño de un sistema de gobernanza no es una medición de su eficacia. De hecho, los sistemas elaborados para la gobernanza (como los que se encuentran en muchas grandes empresas) pueden limitar la velocidad y la frecuencia de las versiones. La buena gobernanza consiste en dificultar que las personalizaciones incorrectas superen las etapas tempranas del desarrollo y obtener buenas personalizaciones en producción de forma predecible y coherente. Con demasiada frecuencia, los esfuerzos de gobernanza son reaccionarios. Se inician o redoblan cuando un problema, como una deuda técnica excesiva, comienza a convertirse en un problema de negocio. En muchos casos, la respuesta desafortunada es que el negocio “bloquee” los esfuerzos y las versiones de desarrollo, en vez de crear [estándares de diseño](/docs/architect/es-mx/resources/guide/design-standards-template) efectivos y crear automatización para aplicar esos estándares en cadenas de herramientas de desarrollador y sistemas de control de origen. Cuando cree el marco de trabajo para su sistema de gobernanza de Salesforce, incluya los siguientes elementos y considere estas preguntas clave para responder: - **Solicitudes de trabajo.** ¿Cómo pueden los usuarios solicitar funciones o características? ¿Cómo se reportan los fallos? - **Priorización y planificación de trabajo.** ¿Quién decide qué solicitudes de trabajo importan? ¿Cómo se define el ámbito, la prioridad y la aceptación o el inicio de sesión del trabajo? - **Entornos y planificación de versiones.** ¿Cuál es la canalización de entorno para el desarrollo, las pruebas y la versión? ¿Quién hace qué para aprovisionar, actualizar y proporcionar acceso? ¿Quién gestiona las implementaciones y la validación? ¿Cómo y cuándo se publican los cambios? ¿Cómo gestiona implementaciones o entornos durante un ciclo de versión de Salesforce? (Para obtener más información sobre esto, consulte [Gestión del ciclo](/docs/architect/es-mx/well-architected/guide/resilient#gestión-del-ciclo-de-vida-de-aplicaciones) de vida de la aplicación.) - **Propiedad del servicio y asistencia de producción.** ¿Quién admite qué? ¿Quién gestiona problemas de producción de “solución rápida”? ¿Cómo se prueban y se publican esos elementos? ¿Quién es responsable de los estándares de seguridad generales de la organización? La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/intentional#patrones-de-estrategia-y-antipatrones) a continuación muestra el aspecto de la gobernanza adecuada (y deficiente) para una organización de Salesforce. Puede utilizarlos para validar o mejorar su estrategia de gobernanza. Para obtener más información acerca de las herramientas de Salesforce disponibles para la gobernanza, consulte [Herramientas relevantes para intencionado](/docs/architect/es-mx/well-architected/guide/intentional#herramientas-relevantes-para-intencional). ### Patrones de estrategia y antipatrones La siguiente tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su corrección. ✨ Descubra más patrones para la estrategia en el [Explorador de patrones](/docs/architect/es-mx/well-architected-tools/guide/easy-strategy) y antipatrones.

	Patrones	Antipatrones
Priorización	En su documentación: - Todos los nuevos elementos de trabajo tienen mediciones de valor de negocio claras (por ejemplo, aumentos de ingresos, ahorros de costos de optimizaciones de procesos, etc.) - Las hojas de ruta muestran el trabajo priorizado en base al valor de negocio	En su documentación: - El valor de negocio asociado con el trabajo no está claro o no existe - Las hojas de ruta no existen
Priorización	Dentro de su compañía: - Se han identificado los costes de implementación y mantenimiento de todos los elementos de trabajo - Las solicitudes de funciones se priorizan basándose en la repercusión de negocio, la cantidad de nuevo trabajo requerido para entregar y la cantidad de trabajo requerido para mantener	Dentro de su compañía: - Los costos asociados con la implementación y el mantenimiento de funciones no están claros - Las solicitudes se entregan de forma ad hoc o según el orden de llegada/primera salida
Hoja de ruta	Hojas de ruta: - Comunicar información adaptada a su audiencia (empresarial o técnica) - Comunicar la información con el nivel de detalle correcto - Mostrar fechas de inicio y finalización - Mostrar requisitos previos y dependencias	Hojas de ruta (si existen): - Se utilizan como materiales de inicio de proyecto y no artefactos para entrega - No ayudar a alinear partes interesadas y equipos de entrega - Mezclar niveles de detalle (por ejemplo, incluyendo sistemas y componentes en la misma hoja de ruta) - Contener información que no está adaptada a su audiencia (por ejemplo, funciones de negocio y sistemas dentro de la misma hoja de ruta)
Hoja de ruta	Dentro de su negocio: - Las partes interesadas comprenden el "por qué" de los elementos de trabajo - Los equipos de entrega saben cómo evaluar elementos atrasados frente a prioridades a largo plazo - Los equipos saben quién está haciendo qué y cómo gestionar dependencias - El trabajo es intencionado, incluso cuando las prioridades tienen que cambiar rápidamente	Dentro de su negocio: - El trabajo se extrae de lo que haya en el atraso y no hay un “por qué” claro - Los equipos tienen problemas para coordinar el trabajo interdependiente y a menudo replican el trabajo sin darse cuenta - El trabajo es a menudo reactivo - Las partes interesadas a menudo se sienten frustradas y confundidas acerca de lo que se está haciendo y son usura cuando se entregarán nuevas funciones
Gobernanza	Dentro de su negocio: - Los usuarios pueden reportar fácilmente fallos y solicitar funciones El proceso de priorización de los elementos de trabajo está documentado y es transparente para todas las partes interesadas - La estrategia de entorno está claramente documentada y los entornos de desarrollo coinciden con la documentación - La planificación de versiones es predecible y transparente para todos los miembros del equipo de entrega - Los miembros del equipo saben quién es responsable de qué a lo largo del ciclo de vida de la aplicación - Las versiones son claras para usuarios y equipos de entrega/mantenimiento - Los procesos de asistencia de producción son claros y las soluciones tienen una ruta clara a la producción - Los equipos y proyectos solo utilizan modelos de IA aprobados para usos de negocio	Dentro de su negocio: - Los reportes de fallos y las solicitudes de funciones son ad hoc - Los elementos de trabajo no tienen prioridad clara - Los entornos se proporcionan ad hoc y pueden no actualizarse de forma predecible; los desarrolladores a menudo no tienen los entornos y el acceso que necesitan - Las versiones son impredecibles para usuarios y equipos de entrega - Los equipos no saben quién es responsable de qué - Las revisiones se solucionan ad hoc - Su retraso se ha convertido en un “banco de ideas” que está obsoleto y estancado - Los órganos de gobierno actúan como una mesa de ayuda que soluciona problemas de solicitudes de asistencia - La documentación no es fácilmente accesible - Los equipos seleccionan modelos de IA ad hoc

## Mantenibilidad La capacidad de mantenimiento significa que un sistema puede mantenerse en un estado saludable, con nuevas funciones moviéndose hacia y deudas técnicas moviéndose fuera del sistema de forma regular y predecible. Los sistemas con capacidad de mantenimiento permiten a sus equipos ofrecer valor al negocio con velocidad y calidad predecibles. La capacidad de mantenimiento de un sistema depende de varios factores, incluyendo cuán legible es, cuán poco acoplado está y cuán minuciosa es su estrategia de prueba. Lo que es más importante, la capacidad de mantenimiento de un sistema depende de la sencillez de su diseño. Esta sección trata formas de crear diseños de soluciones más sencillos y aumentar la capacidad de mantenimiento. Puede crear soluciones que son más fáciles de mantener centrándose en dos claves: el uso de funciones estándar sobre personalizadas y la gestión de deudas técnicas. ### Estándar frente a funciones personalizadas Salesforce ofrece una gama de soluciones preconstruidas: Sales Cloud, Service Cloud y muchas soluciones de la industria de Salesforce, así como la flexibilidad de crear sus propias soluciones personalizadas. Los servicios fundacionales que impulsan las soluciones en la nube propias de Salesforce también están disponibles para cualquier solución personalizada creada sobre Salesforce Customer 360 Platform. Utilice los servicios y soluciones preintegrados de Salesforce como base de confianza para el mayor número posible de sus soluciones. El uso de servicios de plataforma preintegrados tiene dos beneficios distintos. En primer lugar, sus aplicaciones se benefician naturalmente de las últimas innovaciones de Salesforce con cada versión. En segundo lugar, sus equipos de desarrollo pueden centrarse en ampliar y profundizar las funciones de negocio proporcionadas por sus soluciones de Salesforce en vez de gestionar tareas pesadas de arquitectura básica. Seleccionar correctamente cuándo utilizar funciones estándar y cuándo crear funciones personalizadas no es un reto desde el punto de vista arquitectónico. Las claves son: - **Personalizar la plataforma significa modificar y ampliar, no copiar**. A medida que diseña o evalúa su arquitectura, debe preguntar: ¿Existe ya esto en algún punto de la plataforma Salesforce? Si la respuesta es “_Sí, pero...\[inserte cambios que una parte interesada de negocio desea aquí...]”_, utilice la función preconstruida en la plataforma. El trabajo arquitectónico que se debe realizar es identificar las formas más útiles de configurar la función de Salesforce preconstruida para cumplir las expectativas de negocio. - **Ninguna personalización es trivial**. Con el tiempo, cada cambio tiene consecuencias. Si necesita implementar una solución personalizada, puede mitigar la inevitable [deuda técnica](/docs/architect/es-mx/well-architected/guide/intentional#deuda-técnica) que generará su sistema seleccionando utilizar tecnología de código bajo siempre que sea posible y creando [unidades con capacidad](/docs/architect/es-mx/well-architected/guide/composable) de composición en sus implementaciones. - **Considere el espectro build-buy**. [Salesforce AppExchange](https://appexchange.salesforce.com/) es un mercado de aplicaciones y soluciones para ampliar Salesforce. Las aplicaciones AppExchange pueden entregar funciones sin la carga de trabajo que implica crear y mantener una solución personalizada. Tenga en cuenta lo siguiente cuando evalúe soluciones AppExchange: - Identifique funciones y brechas de soluciones. Idealmente, encontrará una aplicación que cumple todos sus requisitos de negocio. En realidad, es posible que no encuentre un ajuste perfecto. A medida que evalúa soluciones, asigne funciones en la solución potencial a una lista priorizada de requisitos de negocio. Esto le ayudará a encontrar la solución que mejor se ajuste a sus requisitos más críticos. - Utilice sandboxes y pruebas gratuitas. Utilice periodos de prueba gratuitos para evaluar aplicaciones en entornos sandbox e identificar el mejor ajuste. Determine si las aplicaciones le requerirán realizar cambios de configuración que entren en conflicto con su configuración existente. - Considere costos a corto y largo plazo. Evalúe los ahorros de mantenimiento de aplicaciones a largo plazo frente a los costos recurrentes de aplicaciones basadas en suscripciones. Evite escenarios donde tenga que pagar costos recurrentes por muchas funciones que sus partes interesadas de negocio nunca utilizarán. - **Utilice los modelos de datos preintegrados desde Salesforce.** Salesforce proporciona modelos de datos preintegrados para Ventas, Servicio y una variedad de verticales de la industria. El uso de los modelos de datos proporcionados por Salesforce garantiza que las funciones en su sistema se definan solo una vez (eliminando la redundancia y los silos), establece una única fuente de verdad en todo el sistema, facilita la comprensión de los datos de la aplicación con análisis, facilita el uso de los servicios de inteligencia artificial preintegrados de Salesforce, reduce los costos de mantenimiento (reduciendo las personalizaciones que necesita asistencia) y reduce la deuda técnica. Así de simple. Como puede ver en los [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/intentional#patrones-de-mantenimiento-y-antipatrones) a continuación, los antipatrones se reducen a la replicación de funciones estándar en una solución personalizada o el uso de tecnología más compleja para entregar personalizaciones. En la práctica, es posible que se encuentre con un escenario en el que las partes interesadas de negocio vean un antipatrón de funciones personalizado como la mejor o única forma viable de avanzar. En estos casos, es esencial que explique a las partes interesadas las compensaciones implicadas en la elección de esta ruta y luego documente minuciosamente la decisión, su justificación y su implementación. Este es también un área donde la entrega de valor principal de forma temprana y la adaptación con el tiempo pueden ayudar a sus partes interesadas a comprender mejor el mejor camino a seguir. Para obtener más información acerca de herramientas de Salesforce que pueden ayudarle a aumentar la capacidad de mantenimiento, consulte [Herramientas relevantes para intencionado](/docs/architect/es-mx/well-architected/guide/intentional#herramientas-relevantes-para-intencional). ### Deuda técnica La deuda técnica es una parte natural de cualquier sistema. Los diseños de sonido de ayer pueden convertirse en antipatrones cuando cambian las necesidades de tecnología o negocio. Quizás algo creado para rellenar un vacío en la funcionalidad de la plataforma Salesforce de repente se convierte en redundante con una nueva versión de Salesforce o lanzamiento de producto. Quizás una tecnología de mayor desempeño o flexible sustituya a una tecnología que ya implementó. La deuda técnica se puede crear de muchas formas. Un beneficio clave de la creación de aplicaciones con Salesforce Customer 360 Platform es la [retrocompatibilidad incorporada en](/docs/architect/es-mx/fundamentals/guide/architecture-basics#api-de-plataforma) la plataforma. Esto significa que las nuevas innovaciones de plataforma pueden cambiar el patrón que debe utilizar para soluciones que avanzan, pero la función diaria de soluciones que creó en tecnologías anteriores de Salesforce seguirá funcionando. Con el tiempo, cualquier solución basada en tecnología antigua comenzará a plantear riesgos o cuellos de botella para agregar nuevas funciones a sus aplicaciones, y disminuirá el estado general de la solución. La planificación y la realización de trabajo regular para abordar la deuda técnica es esencial para mantener diseños sencillos y saludables en una solución de Salesforce. No planificar, auditar y remediar deudas técnicas es una forma segura de crear un sistema mal diseñado. Una forma de minimizar la deuda técnica es evitar introducirla en la medida de lo posible, evitando accesos directos y prefiriendo la [funcionalidad estándar sobre](/docs/architect/es-mx/well-architected/guide/intentional#estándar-frente-a-funciones-personalizadas) la personalizada. Los accesos directos, como los valores de codificación permanente, pueden ser tentadores para ahorrar tiempo, pero a largo plazo crean deudas que se deben pagar. Las claves para abordar la deuda técnica desde una perspectiva arquitectónica incluyen: - Identificación del [costo o beneficios](/docs/architect/es-mx/resources/guide/kpi-spreadsheet-template) reales para el negocio de acción frente a la inacción - [Hoja de ruta](/docs/architect/es-mx/well-architected/guide/intentional#hoja-de-ruta) adecuada - Creación de [soluciones componebles](/docs/architect/es-mx/well-architected/guide/composable) La dificultad puede ser conseguir que las partes interesadas estén alineadas con la acción. Es posible que algunas partes interesadas perciban que el mantenimiento continuo soluciona “los errores de ayer” o elimina las funciones que desean que admita su presupuesto. Mostrar las repercusiones reales de la acción y la inacción en el negocio, junto con plazos y entregas claramente definidos, puede ayudar a sus partes interesadas a comprender el valor y la prioridad relativa de abordar la deuda técnica. Hacer el trabajo de forma coherente para conectar la deuda técnica con impactos de negocio no solo ayudará a sus partes interesadas a comprender mejor el trabajo que se debe realizar. También le ayudará a asegurarse de que está identificando y abordando la deuda técnica de formas que realmente benefician a los usuarios. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/intentional#patrones-de-mantenimiento-y-antipatrones) a continuación muestra el aspecto adecuado (y deficiente) de la gestión de deudas técnicas para una organización de Salesforce. Para obtener más información acerca de herramientas de Salesforce que pueden ayudarle con deudas técnicas, consulte [Herramientas relevantes para intencionado](/docs/architect/es-mx/well-architected/guide/intentional#herramientas-relevantes-para-intencional). ### Patrones de mantenimiento y antipatrones La siguiente tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su corrección. ✨ Descubra más patrones para la capacidad de mantenimiento en el [Explorador de patrones](/docs/architect/es-mx/well-architected-tools/guide/easy-maintainability) y antipatrones.

	Patrones	Antipatrones
Estándar frente a Personalizado	En sus estándares de diseño: - Existe un principio rector claro para evitar que las soluciones se personalicen innecesariamente - El principio rector para las soluciones utiliza la siguiente prioridad: 1. Utilice servicios de plataforma integrados, 2. Tenga en cuenta las aplicaciones AppExchange antes de crear una solución personalizada, 3. Utilizar personalizaciones de código bajo antes de redactar código	En sus estándares de diseño: - Los estándares de diseño no existen o no tienen una justificación clara para evitar personalizaciones y códigos innecesarios
	En su documentación: - Los registros de decisiones muestran el cálculo de costos a corto y largo plazo al elegir construir o comprar soluciones	En su documentación: - Los registros de decisiones no tienen en cuenta los costos a corto y largo plazo al elegir construir o comprar soluciones
	En modelos de datos: - Ningún objeto tiene nombres o funciones que dupliquen objetos estándar - Los objetos estándar no se utilizan para fines que están muy fuera de su ámbito previsto	En modelos de datos: - Los objetos duplican los nombres y/o funciones de objetos estándar - Los objetos estándar se utilizan para fines muy fuera de su ámbito previsto
	En LWC, Aura o Visualforce: - No existe código para sustituir mecanismos de vista de página estándar	En LWC, Aura o Visualforce: - El código existe para sustituir mecanismos de vista de página estándar, a menudo en forma de una sola aplicación de página
	En LWC, Aura o Apex: - Ningún código intenta sustituir o eludir el orden de ejecución de la plataforma	En LWC, Aura o Apex: - El código intenta sustituir o eludir el orden de ejecución de la plataforma
Deuda técnica	En su hoja de ruta: - Se planifica el trabajo para abordar la deuda tecnológica - Los entregables y las fechas de inicio/finalización están claros	En su hoja de ruta: - No se planifica ningún trabajo para abordar la deuda tecnológica - Los entregables son vagos; las fechas de inicio/finalización no están claras
	En sus registros de decisiones: - Los KPI para la solución de la deuda pre/post-tecnológica están claramente documentados - Los debates de compensación para la acción y la inacción se centran en costos o beneficios de negocio	En sus registros de decisiones: - La solución de deudas tecnológicas no tiene indicadores clave de desempeño mensurables - La deuda tecnológica se considera en términos técnicos o centrados en TI, sin relevancia para el negocio
	En su organización: - Ninguna tecnología no compatible o heredada está activa, incluyendo: -- Todos los usuarios trabajan en Lightning Experience -- ninguno o muy pocos usos de `@future` en Apex (se utiliza Colocable en cola) -- Todos los Apex externos pertenecen a paquetes AppExchange -- no hay reglas de flujo de trabajo activas (se utiliza Flujo) -- no hay procesos de Process Builder activos (se utiliza Flujo) -- Eventos de envío de temas (se utiliza Captura de datos de cambios) -- Eventos genéricos (se utilizan Eventos de plataforma) -- Versiones de API anteriores a 30.0 -- Las conexiones de organizaciones de Salesforce utilizan el adaptador entre organizaciones para Salesforce Connect	En su organización: - La tecnología no admitida o heredada está activa, incluyendo: -- Usuarios que trabajan en Salesforce Classic -- Uso `@future` en Apex -- Apex externo desde fuentes que no son AppExchange -- Reglas de flujo de trabajo -- Procesos de Process Builder -- Eventos de PushTopic -- Eventos genéricos -- Versiones de API anteriores a 30.0 -- Conexiones de Salesforce a Salesforce

## Legibilidad En esencia, el concepto de _legibilidad_ consiste en crear coherencia que facilita a las personas la comprensión de cómo funcionan las cosas. La construcción de sistemas legibles alinea los equipos de entrega y mantenimiento, y ayuda a las personas que no están familiarizadas con el sistema a comprender rápidamente cómo encajan las piezas. Significa que su equipo puede depender menos de personas individuales con Knowledge institucional o histórico para incorporar de forma efectiva proveedores o nuevos miembros del equipo. Significa que las personas cualificadas en un equipo pueden centrarse en la calidad y las ventajas de las opciones que se están realizando, porque la configuración y el código del sistema son fáciles de leer y comprender para los humanos. La capacidad de lectura puede acelerar los procesos de gobernanza y garantía de calidad, y ayudar los equipos a identificar mejor cuándo podrían estar creando personalizaciones redundantes. También puede potenciar las posibilidades de tener un sistema que se comporte de formas que sean reutilizables y comprobables. Puede aumentar la legibilidad a través de estándares de diseño y documentación efectivos. ### Estándares de diseño Los [estándares de diseño](/docs/architect/es-mx/resources/guide/design-standards-template) proporcionan directrices para mantener todas las personalizaciones coherentes, incluso en las etapas más tempranas del desarrollo. Los estándares de diseño actúan como salvaguardas, manteniendo todos los equipos de entrega y mantenimiento trabajando en su sistema alineados sobre cómo abordar e implementar personalizaciones. La definición de estándares de diseño ayuda a potenciar la productividad de sus equipos de entrega y mantenimiento, facilita la realización de revisiones de código y arquitectura y proporciona una base para una mejor [documentación](/docs/architect/es-mx/well-architected/guide/intentional#documentación). Sin estándares de diseño, los equipos tienen más probabilidades de trabajar en silos. Sin la coherencia que proporcionan los estándares de diseño, los negocios se encontrarán en dificultades con: - Vendedores y equipos de desarrollo que utilizan patrones y enfoques ad hoc entre soluciones, lo que podría introducir antipatrones y reducir la reutilización (consulte [Separación de preocupaciones](/docs/architect/es-mx/well-architected/guide/composable#separación-de-preocupaciones)). - Tiempo aumentado para resolver problemas de producción, y equipos de asistencia requeridos para incorporar nuevos miembros del equipo y ayudarles a comprender un conjunto dispar de patrones y enfoques. - Mala colaboración entre equipos, redundancias en el trabajo entre equipos, tiempo perdido resolviendo conflictos y fallos descubiertos durante las pruebas de integración. - Mayor frustración y mayores índices de rotación. Un beneficio clave de los estándares de diseño se deriva de las pláticas y las decisiones que las partes interesadas deben tomar para crearlos. Específicamente, el proceso proporciona a sus prospectos de negocio y tecnología la oportunidad de alinearse en torno al aspecto óptimo del diseño para su negocio. Incluya lo siguiente en sus [estándares de diseño](/docs/architect/es-mx/resources/guide/design-standards-template) - **Convenciones de nomenclatura para metadatos de Salesforce**. Defina un conjunto de convenciones para el nombre de cada personalización en un sistema. Las buenas convenciones de nomenclatura no solo aplican la coherencia entre los nombres de objetos, campos, códigos, flujos y otros elementos de su sistema. Las buenas convenciones de nomenclatura también ayudan a los equipos de desarrollo a utilizar nombres que transmiten información acerca del propósito y las funciones de lo que están creando. Como resultado, otras partes interesadas pueden comprender mejor una personalización concreta, solo viendo su nombre. - **Patrones de diseño aprobados y sus casos de uso**. Establezca una biblioteca de [Patrones y Explorador](/docs/architect/es-mx/well-architected-tools/guide/patterns) de antipatrones, junto con información clave acerca de cuándo (y cuándo no) utilizar cada patrón. La biblioteca podría incluir patrones de desencadenador Apex obligatorios o patrones de orquestación de flujos basándose en la [capacidad de composición](/docs/architect/es-mx/well-architected/guide/composable) que desea en su sistema. - **Entorno de desarrollo y directrices sobre** herramientas. Mantenga una lista clara de las herramientas que los equipos de desarrollo deben utilizar para su trabajo. Esto podría incluir idiomas y cadenas de herramientas aprobados para cualquiera que escriba código, o funciones declarativas que están (o no) aprobadas para el desarrollo de código bajo. Sus estándares podrían incluir una lista de sistemas de control de origen para la personalización y la documentación, así como pasos de registro/salida obligatorios. También pueden incluir una lista de entornos que se utilizarán para diferentes tipos de trabajo de desarrollo. Junto con la definición de estos estándares, deberá decidir cómo y dónde mantenerlos y almacenarlos. Si los equipos de toda su compañía no pueden encontrar sus estándares de diseño (o ni siquiera saben que existen), no serán efectivos. Idealmente, sus estándares de diseño viven dentro del mismo sistema que su documentación (consulte la siguiente sección para obtener más información). La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/intentional#patrones-de-legibilidad-y-antipatrones) a continuación muestra el aspecto de los estándares de diseño apropiados (y deficientes) para una organización de Salesforce. Puede utilizarlos para validar o mejorar sus estándares de diseño. Para obtener más información acerca de herramientas de Salesforce que pueden ayudarle a definir estándares de diseño, consulte [Herramientas relevantes para intencionado](/docs/architect/es-mx/well-architected/guide/intentional#herramientas-relevantes-para-intencional). ### Documentación La documentación explica qué, cómo y por qué de su sistema. Sin documentación significativa y coherente, los equipos pierden mucho tiempo intentando comprender el sistema tal cual es (y posiblemente malinterpretando funciones y personalizaciones). Una buena documentación tarda tiempo en crearse. Aunque la mayoría de los equipos están de acuerdo en que la documentación es importante para proyectos de gran tamaño, puede ser un paso tentador omitir al realizar cambios rápidos como actualizaciones de configuración o pequeños ajustes en una automatización. No documentar los cambios que realiza en su sistema siempre es un antipatrón. Omitir la documentación puede ahorrar una pequeña cantidad de tiempo por adelantado, pero la cantidad de tiempo requerida para solucionar problemas de una organización que no está debidamente documentada cancelará con creces esos ahorros de tiempo. Incluya siempre tiempo suficiente para crear documentación en todas sus estimaciones, independientemente del nivel de esfuerzo requerido para las actualizaciones que está planificando realizar. La falta de documentación clara puede provocar diversos problemas, entre ellos: - Ciclos de desarrollo empleados en la reelaboración de implementaciones existentes - Debates repetitivos que vuelven a visitar decisiones anteriores o que desconciertan su contenido - Incorporación más larga para nuevos miembros del equipo o proveedores - Excesiva dependencia de individuos con Knowledge institucional o histórico - Arquitecturas redundantes para admitir las mismas funciones o funciones similares en todo el negocio - Dificultad para comunicar el propósito y el valor de su solución a partes interesadas clave Para soluciones de Salesforce, mantenga la documentación para: - **Descripciones generales de** soluciones. Los [diagramas](/docs/architect/es-mx/reference-diagrams/guide/introduction) le permiten a usted y a sus partes interesadas visualizar soluciones con varios niveles de detalle. El marco de trabajo de diagramas de Salesforce le ayuda a crear diagramas que muestran las funciones de negocio de soluciones, así como detalles de implementación técnica. - **Registros de decisiones**. Mantenga un registro de las opciones consideradas, las compensaciones, la decisión final y el razonamiento en una ubicación central a la que todos los miembros del equipo puedan acceder para futuras referencias. - **Código**. El formato del código en sí es una pieza clave de la documentación, y esto puede (y debe) alinearse con sus [estándares de diseño](/docs/architect/es-mx/well-architected/guide/intentional#estándares-de-diseño). También querrá tener un registro de información clave y actualizarlo con cada modificación de un fragmento de código. Para todas las clases, desencadenadores y componentes, documente lo siguiente: - Quién redactó el código - Cuando se redactó el código - Lo que se supone que debe hacer el código - Dependencias clave - Todos los cambios - **Personalización declarativa**. Para cada tipo de personalización que se puede realizar en los metadatos en su organización, Salesforce proporciona [atributos integrados](/docs/architect/es-mx/fundamentals/guide/platform-multitenant-architecture#desarrollo-de-aplicaciones-basado-en-navegador-sin-código-y-de-código-bajo) para que los equipos proporcionen información útil acerca del propósito y la intención de los metadatos. Como parte de sus estándares de diseño, incluya cómo utilizarán los equipos estas funciones integradas y cómo asignarán nombres a personalizaciones declarativas. Mantenga también un registro de información clave idéntica a la que utiliza para el código. Desarrolle un conjunto de estándares de documentación para garantizar que todos los miembros del equipo actuales y futuros puedan interpretar documentos de la misma forma. ([los estándares de diseño](/docs/architect/es-mx/resources/guide/design-standards-template) pueden ayudar con esto.) También es importante considerar cómo los usuarios podrán buscar documentación para encontrar secciones o términos relevantes. A medida que su sistema envejece y crece en complejidad, su documentación también crecerá. La utilidad de la información en su documentación estará directamente relacionada con la frecuencia, la rapidez y la facilidad con la que los usuarios pueden buscar y encontrar elementos relevantes. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/intentional#patrones-de-legibilidad-y-antipatrones) a continuación muestra el aspecto de la documentación adecuada (y deficiente) para una organización de Salesforce. Puede utilizarlos para validar o mejorar su estrategia de documentación. Para obtener más información acerca de las herramientas de Salesforce para la documentación, consulte [Herramientas relevantes para intencionado](/docs/architect/es-mx/well-architected/guide/intentional#herramientas-relevantes-para-intencional). ### Patrones de legibilidad y antipatrones La siguiente tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su corrección. ✨ Descubra más patrones para la legibilidad en el [Explorador de patrones](/docs/architect/es-mx/well-architected-tools/guide/easy-readability) y antipatrones.

	Patrones	Antipatrones
Normas de diseño	En su organización: - El código y las personalizaciones declarativas tienen nombres coherentes y legibles por humanos - Los modelos de datos tienen nombres uniformes y coherentes para objetos y campos - Las auditorías muestran que los campos se rellenan de forma coherente y se hace referencia a ellos en reportes, etc.	En su organización: - El código y las personalizaciones declarativas no tienen nombres coherentes - Los modelos de datos tienen nombres incoherentes y muchos objetos y campos parecen ser redundantes - Las auditorías muestran muchos campos no utilizados o varios niveles de uso, y no hay un vínculo coherente a la creación de reportes, etc.
Normas de diseño	Dentro de su negocio: - Los equipos saben qué herramientas utilizar (y no utilizar) para realizar el trabajo - Los patrones de diseño aprobados son fáciles de encontrar e identificar por caso de uso - Los modelos de IA aprobados están claramente identificados e incluyen un propósito previsto	Dentro de su negocio: - Los equipos utilizan muchas herramientas diferentes para realizar un trabajo similar - No hay patrones de diseño aprobados -Lleva mucho tiempo para que los proveedores o nuevos empleados se incorporen - Los modelos de IA aprobados no están claramente identificados, y su propósito previsto no está claro
Documentación	En su organización: - El código y las personalizaciones declarativas tienen descripciones claras	En su organización: - El código y las personalizaciones declarativas no tienen descripciones, tienen descripciones difíciles de comprender o tienen descripciones que no parecen coincidir con lo que la personalización está haciendo actualmente
Documentación	Dentro de su negocio: - Existen diagramas para funciones de negocio y detalles de implementación técnica para todas las soluciones - Clave quién/cuándo/qué registros de información existen para personalizaciones de código y declarativas - Las personas pueden buscar y encontrar documentación relevante	Dentro de su negocio: - El qué/cómo/por qué de las soluciones es difícil de encontrar y puede no estar disponible para la mayoría de los equipos - Las personas luchan por comprender las soluciones y el sistema con el que están trabajando -Lleva mucho tiempo para que los proveedores o nuevos empleados se incorporen

## Herramientas relevantes para intencional

Herramienta	Descripción	Estrategia	Mantenibilidad	Legibilidad
ApexDoc	Documento Apex con páginas HTML estáticas		X	X
Eliminar de forma masiva valores de lista de selección inactivos	Eliminar valores no utilizados inactivos de listas de selección		X
Validador del sistema Lightning Design	Validar marcado y ver cómo mejorar su código		X	X
Migrar a flujo	Convertir reglas de flujo de trabajo y procesos de Process Builder en flujos		X
Herramienta de gestión de proyectos de Salesforce Labs	Gestionar proyectos en su organización de Salesforce	X	X
Extensiones de Salesforce para Visual Studio Code (ampliado)	Analizar código de Salesforce de forma eficiente con extensiones de Visual Studio Code		X	X
Comprobación de organización	Analizar rápidamente su organización y su deuda técnica		X
Analizador de código de Salesforce	Escanee código a través de IDE, CLI o CI/CD para asegurarse de que se ajusta a las mejores prácticas		X	X
Explorador de hojas de ruta de Salesforce	Explorar innovaciones de productos de Salesforce	X
Configurar seguimiento de auditoría	Realizar un seguimiento de cambios de configuración e historial de auditoría	X	X

## Recursos relevantes para intencional

Recurso	Descripción	Estrategia	Mantenibilidad	Legibilidad
5 estrategias de documentación para mejorar su organización de Salesforce	Mejorar la documentación de implementación de Salesforce	X
Seleccionar convenciones de nomenclatura (Trailhead)	Aprenda cómo aplicar convenciones de nomenclatura			X
Definición, identificación y medición de deuda técnica	Definir, identificar y medir la deuda técnica	X	X
Plantilla de estándares de diseño	Crear estándares de diseño para su organización	X	X	X
Primeros pasos con diagramas de Salesforce	Aprenda cómo crear el diagrama correcto para su caso de uso			X
Primeros pasos con convenciones de codificación (Trailhead)	Definir y seguir convenciones de codificación			X
Cómo abordar la deuda técnica (Trailhead)	Gestionar deudas técnicas en su organización de Salesforce	X	X
Mejorar su código Apex (Trailhead)	Aplicar principios básicos de desarrollo dirigido por pruebas			X
Alineación organizativa (Trailhead)	Aprender el proceso V2MOM para la alineación	X
Priorización y planificación de una salida a la deuda técnica	Formular un plan para reducir y eliminar la deuda técnica	X	X
Plantilla Convenciones de nomenclatura de Salesforce	Empezar a trabajar con convenciones de nomenclatura		X	X
Deuda técnica: ¿Qué es y por qué debería importarle?	Comprender el impacto de la deuda técnica en su organización		X
Uso del lienzo de modelo de negocio en Arquitectura de negocio	Crear, entregar y ver valor en un modelo de negocio	X

## Dinos lo que piensas Ayúdenos a mantener Salesforce Well-Architected relevante para usted; realice nuestra [encuesta](https://sfdc.co/bxNtvh) para proporcionar comentarios sobre este contenido e indicarnos qué le gustaría ver a continuación. > Lea sobre nuestras programaciones de actualizaciones [aquí](/docs/architect/es-mx/well-architected/guide/contributors). ## Introducción Las soluciones resilientes mantienen una alta calidad de servicio incluso cuando se producen fallos. Si el desempeño se degrada o se interrumpe el servicio, la solución se recupera de forma rápida y efectiva. La resistencia de una solución se basa en dos cualidades clave: - **Dureza**: Cuando se producen problemas, la solución los resiste y los soporta. - **Elasticidad**: Después de resolver los problemas, la solución vuelve a su estado o forma ideal. Para diseñar su solución para la resiliencia, debe diseñar para la tenacidad y la elasticidad, garantizando la durabilidad y la recuperación rápida ante cambios planificados y no planificados. En contextos de tecnología, considere un sistema o una solución como un conjunto de componentes interdependientes que se coordinan para realizar objetivos compartidos. Cada componente tiene el potencial de fallar. Los problemas en esos componentes, desde defectos de código y configuración hasta problemas de red y hardware, pueden causar comportamientos inesperados no deseados. Un sistema demuestra un comportamiento resistente cuando uno o más componentes fallan, pero el sistema general continúa funcionando o vuelve rápidamente a un estado estable. Para mejorar la resistencia de sus soluciones de Salesforce, recomendamos centrarse en tres hábitos clave. - [**Gestión del ciclo de vida de aplicaciones (ALM)**](/docs/architect/es-mx/well-architected/guide/resilient#gestión-del-ciclo-de-vida-de-aplicaciones): cómo gestionan los equipos el software a lo largo de su ciclo de vida, desde la ideación hasta la retirada - [**Respuesta ante incidentes**](/docs/architect/es-mx/well-architected/guide/resilient#respuesta-de-incidente): Cómo los equipos identifican, solucionan y evitan problemas que afectan a la disponibilidad o la seguridad de un sistema - [**Planificación de continuidad**](/docs/architect/es-mx/well-architected/guide/resilient#planificación-de-continuidad): Cómo planifican los equipos que sus personas y sistemas sigan funcionando cuando los eventos no planificados causan problemas ## Gestión del ciclo de vida de aplicaciones La gestión del ciclo de vida de aplicaciones (ALM) es una práctica para gestionar software de forma integral a lo largo de su ciclo de vida, desde la creación hasta la retirada. ALM es una piedra angular de la resiliencia del sistema y abarca personas, procesos, herramientas y disciplinas relacionadas con el ciclo de vida de la aplicación. Esas disciplinas incluyen DevOps y metodologías de entrega, observabilidad, estrategias de prueba, gobernanza e CI/CD. Cuando un negocio practica ALM efectivo, sus equipos reaccionan rápidamente al cambio y sus aplicaciones se mantienen al día con los requisitos de negocio en evolución sin comprometer la estabilidad o la calidad. Por otro lado, sin ALM saludable, los equipos tienen dificultades en cada etapa del ciclo de vida de la aplicación. Los síntomas de ALM deficiente incluyen: - Ciclos de desarrollo lentos y proclives a errores - Implementaciones intensivas y difíciles - Problemas o fallos de alta gravedad descubiertos en entornos de producción y posteriores a la evaluación cualitativa - Agentes de IA que alucinan o se comportan de forma incoherente - Reversiones frecuentes o implementaciones de soluciones rápidas requeridas para estabilizar versiones Como ALM afecta a casi todos los aspectos de una solución, establecer prácticas de ALM claras y efectivas para su solución es una parte clave de su trabajo arquitectónico. Construya mejores prácticas de ALM centrándose en tres áreas clave. - [**Gestión de versiones**](/docs/architect/es-mx/well-architected/guide/resilient#gestión-de-versiones): Planificación, secuenciación, control y migración de cambios a diferentes entornos - [**Estrategia medioambiental**](/docs/architect/es-mx/well-architected/guide/resilient#estrategia-medioambiental): Una estrategia para cómo utilizar y gestionar aplicaciones en entornos de destino durante el desarrollo y las pruebas - [**Estrategia de señalización**](/docs/architect/es-mx/well-architected/guide/resilient#estrategia-de-señalización): Definición de señales críticas e instrumentación de aplicación utilizada para detectar y remediar fallos en el sistema antes de que se produzca la degradación - [**Estrategia de pruebas**](/docs/architect/es-mx/well-architected/guide/resilient#estrategia-de-prueba): Los principios y estándares que guían el modo en que planifica y ejecuta pruebas para medir el éxito de sus aplicaciones durante procesos de ALM ### Gestión de versiones La gestión de versiones implica planificar, secuenciar, controlar y migrar cambios a uno o más entornos. Una única versión es un grupo de cambios planificados que un equipo traslada a un entorno de destino al mismo tiempo. El lanzamiento de un cambio en un sistema introduce riesgo en él. Si el sistema está en un estado estable antes del cambio, pasa a un nuevo estado, donde también es más vulnerable a riesgos de cambios futuros. Si cualquier cambio futuro desencadena un estado inestable e incontrolado en el sistema, puede causar un incidente crítico. En una arquitectura de soluciones, el diseño para versiones resilientes es más que solo [probar cambios individuales](/docs/architect/es-mx/well-architected/guide/resilient#estrategia-de-prueba). También implica planificar cómo introducir cambios en sus sistemas y sus usuarios de forma segura. El trabajo que realizan sus equipos depende de información de versión predecible y precisa. En sus procesos de gestión de cambios y habilitación, tenga claro qué cambios pueden pasar a su sistema. En sus procesos de gestión de versiones y habilitación, especifique cómo (y con qué frecuencia) se publican los cambios en su sistema. Sus partes interesadas de negocio también se preocupan por la información de la versión, especialmente si está relacionada con funciones o soluciones de fallos que solicitan. Para generar Trust en su solución y demostrar valor a sus partes interesadas, establezca programaciones de versiones coherentes y claras y envíe artefactos de versión estables. Para establecer una gestión de versiones efectiva para Salesforce: - **Alinee estrechamente con la arquitectura y la gobernanza del desarrollo**. Asegúrese de que las versiones se planifican con suficiente antelación para alinearse con todos los foros y controles de gobernanza relevantes. Antes de comenzar con el desarrollo, haga que el Consejo de IA revise y apruebe todos los casos de uso de Agentforce priorizados. Obtenga casos de uso de alto riesgo Agentforce revisados por equipos de Uso legal y ético.Utilice listas de comprobación de implementación y documentación para realizar un seguimiento de artefactos de implementación, como nombres de API de agentes Agentforce, frente a actividades de gobernanza. - **No utilice procesos de [desarrollo o versión](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models)** basados en organizaciones. Este paradigma refleja tecnologías más antiguas y limitadas para el desarrollo y la versión. Con Salesforce CLI, los equipos ahora pueden adoptar funciones de versión y desarrollo dirigidas por origen. - **Seleccione el mecanismo de versión más estable posible**. Este enfoque logra dos cosas. En primer lugar, minimiza la duración de los plazos de versión y las interrupciones de servicio. En segundo lugar, permite comportamientos de versión altamente controlados y predecibles. Cuanto más estable sea su mecanismo de versión, menos posibilidades tendrá de que las versiones introduzcan cambios que requieran revisiones o reversiones. Si surge un problema imprevisto, los mecanismos de versión estables también crean formas más sencillas para que el personal de asistencia o los administradores del sistema realicen reversiones. Los mejores mecanismos de versión para su equipo son las opciones más estables para las que su equipo tiene las habilidades requeridas. Estos son los mecanismos de versión recomendados, enumerados en orden de estabilidad. Todos ellos son compatibles entre sí, de modo que utilice varios de ellos en tándem si eso es lo mejor para su compañía. - [**Paquetes desbloqueados**](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_intro.htm): Los paquetes desbloqueados son el artefacto de versión más estable. La implementación de cambios instalando un paquete es la forma más rápida y predecible de introducir cambios. Los paquetes utilizan versiones, lo que permite una gestión de cambios sólida y reversiones precisas y pensadas para administradores del sistema. Además, los paquetes requieren una sólida gestión de metadatos, lo que puede ayudarle a identificar dependencias mal gestionadas de forma temprana. También crean artefactos y oportunidades en curso de desarrollo auditables. Consulte [Capacidad de empaquetado](/docs/architect/es-mx/well-architected/guide/composable#capacidad-de-empaquetado). - [**DevOps Center**](https://help.salesforce.com/s/articleView?id=sf.devops_center_overview.htm&type=5): DevOps Center permite a los equipos de entrega con conjuntos de habilidades de código bajo o procódigo utilizar el control de origen, trabajar en colaboración en cambios y definir rutas de versión comunes. DevOps Center se integra con el control de origen y permite el control de apuntar y hacer clic de cambios e implementaciones. - **Implementaciones de metadatos y desarrollo dirigido por origen utilizando [Salesforce CLI](https://developer.salesforce.com/tools/sfdxcli)**: Si no puede utilizar paquetes, utilice Salesforce CLI para su implementación de metadatos y desarrollo dirigido por origen. No implemente metadatos utilizando el formato package.xml antiguo, que sigue una estructura diferente al [formato de origen](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_source_file_format.htm) recomendado. El formato de origen evolucionó para admitir el desarrollo de paquetes, flujos de trabajo de organizaciones borrador y un seguimiento de cambios más granular en entornos sandbox. El formato es más legible, permite más desvinculación de dependencias y tipos de metadatos complejos y le proporciona mucho más control sobre manifiestos de implementación. - **Asigne un nombre** a sus versiones. Proporcione a sus versiones identificadores claros para ayudar a sus equipos y partes interesadas a permanecer alineados. En Salesforce, el nombre de cada versión principal comienza por “Primavera”, “Verano” o “Invierno”, seguido del año de la versión (por ejemplo, “Verano ’25). Si aún no tiene una convención de nomenclatura para definir y organizar versiones en su compañía, establezca una y utilícela. El uso de nombres de versión claros facilita mantenerse organizado en cada etapa de la planificación, el desarrollo y la entrega en los sistemas de sus equipos. Utilice sus nombres de versión en su [hoja de ruta](/docs/architect/es-mx/well-architected/guide/intentional#hoja-de-ruta) para comunicar claramente a sus partes interesadas qué cambios se aproximan y cuándo. Utilice sus nombres de versión en su documentación, registros de cambios, descripciones de trabajo, comentarios de código y ramas de control de origen de modo que pueda rastrear y auditar fácilmente sus artefactos de desarrollo. - **Dentro de un manifiesto de versión, gestione dependencias correctamente**. Los metadatos de Salesforce tienen dependencias integradas. Una razón común por la que fallan las implementaciones de Salesforce es que las dependencias no están gestionadas correctamente. La selección de un mecanismo de versión estable, como se describió anteriormente, puede ayudar a exponer dependencias mal gestionadas anteriormente en su ciclo de desarrollo. Una de las razones principales por las que los paquetes desbloqueados son el vehículo de versión más estable es su sólida gestión de metadatos, que se requiere para el desarrollo y la creación de paquetes. Si usted o sus equipos de gestión de versiones no comprenden las dependencias integradas entre tipos de metadatos de Salesforce, no podrá detectar combinaciones problemáticas de forma proactiva en sus manifiestos de implementación y versión. Consulte [Gestión de dependencias](/docs/architect/es-mx/well-architected/guide/composable#gestión-de-dependencias). Los [patrones y antipatrones para ALM](/docs/architect/es-mx/well-architected/guide/resilient#patrones-y-antipatrones-de-alm) muestran el aspecto adecuado y deficiente de la gestión de versiones para una organización de Salesforce. Utilice los patrones para validar sus diseños antes de construir, o para identificar lugares en su sistema que necesitan refactorizarse. Para obtener más información acerca de las herramientas de Salesforce para la gestión de versiones, consulte [Herramientas de Salesforce para Resiliencia](/docs/architect/es-mx/well-architected/guide/resilient#herramientas-de-salesforce-para-la-resiliencia). ### Estrategia medioambiental Salesforce proporciona una variedad de [entornos](https://help.salesforce.com/s/articleView?id=sf.create_test_instance.htm&type=5) para que los utilice durante los ciclos de prueba y desarrollo de aplicaciones. Una estrategia de entorno efectiva para Salesforce requiere comprender cómo utilizar los entornos y el aspecto de una buena gestión. En ALM, la utilidad de un entorno de desarrollo o prueba depende de su fidelidad y aislamiento de la producción. Una buena estrategia de entorno proporciona varios beneficios. - Mayor fidelidad a la producción - Configuración y derribos de entornos más rápidos - Más ágil en desarrollo y pruebas - Seguridad mejorada en sus oportunidades en curso - Menos ruido y conflictos en las etapas de entrega - Equipos de desarrollo más felices Los equipos a menudo tienen dificultades para obtener estos beneficios. Los retos para obtener el máximo de sus entornos de desarrollo y estrategia pueden provenir de varios orígenes. Un origen probable es el tipo de modelo de desarrollo que siguen sus equipos. En el enfoque de desarrollo basado en organizaciones más antiguo, cada entorno tenía que cumplir varias funciones. Además de estar donde su equipo realiza sus diversos tipos de trabajo, tenía que ser el origen de sus artefactos de versión (es decir, los metadatos que desea implementar en una versión). Debido a que los entornos no eran fáciles de configurar o derribar, a menudo estaban superpoblados y llenos de conflictos de metadatos entre equipos, y no contribuyen con una velocidad o flexibilidad significativas a ALM en general. El uso de un modelo de desarrollo basado en origen cambia fundamentalmente la relación que tienen los entornos con sus versiones y artefactos de versión. En este modelo, el control de origen es el origen de los metadatos que desea publicar. Los entornos son solo lugares donde sus equipos realizan su trabajo. Sin embargo, seguir el modelo de desarrollo basado en origen no garantiza por sí solo una buena estrategia de entorno. Incluso con el control de origen, los equipos aún pueden tener dificultades para configurar condiciones para probar integraciones con sistemas externos; configuraciones que dependen de metadatos que no están en el control de origen, como paquetes gestionados o personalizaciones que dependen de [datos](/docs/architect/es-mx/fundamentals/guide/architecture-basics#metadatos-frente-a-datos)), etc. En ciertas circunstancias, los retos de un modelo basado en origen son similares a los retos típicos de un modelo basado en organización. Para desarrollar una estrategia de entorno efectiva: - **Adopte un modelo de desarrollo y versión dirigido por origen**. Deje de utilizar modelos de [desarrollo basados en](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models) organizaciones. Consulte [Gestión de versiones](/docs/architect/es-mx/well-architected/guide/resilient#gestión-de-versiones).) Debe desenredar sus entornos de lo que implementa en ellos para crear una estrategia de entorno saludable y versiones más saludables. - **Comprenda los tipos de trabajo que admite cada entorno**. Los tipos de entorno admitidos por Salesforce tienen diferentes funciones y límites. Cuando diseñe su estrategia de entorno, considere lo que los entornos pueden y no pueden hacer. Asegúrese de que sus equipos realizan su trabajo en un entorno que tenga las funciones que necesitan. Para obtener orientación, consulte esta descripción general de los entornos de desarrollo de Salesforce y sus funciones.

	Organización borrador	Developer Sandbox	Sandbox de Developer Pro	Sandbox de copia parcial	Sandbox completo
Admite forma de organización	Sí	No	No	No	No
Admite el seguimiento de origen	Sí	Sí	Sí	No	No
Lifespan	1-30 días	Controlado manualmente	Controlado manualmente	Controlado manualmente	Controlado manualmente
Intervalo de actualización	No disponible	1 día	1 día	5 días	29 días
Compatibilidad de vista previa de versión	Controlado por desarrollador	Basado en instancia de sandbox	Basado en instancia de sandbox	Basado en instancia de sandbox	Basado en instancia de sandbox
Tiempo de aprovisionamiento	> 5 minutos	Horas o días	Horas o días	Horas o días	Horas o días
Metadatos determinados por	Control de origen	Producción	Producción	Producción	Producción
Datos determinados por	Carga de datos manual	Carga de datos manual	Carga de datos manual	Plantilla de sandbox	Producción
Límite de datos	200 MB	200 MB	1 GB	5 GB	Igual que en producción

Consulte esta tabla para obtener información acerca de qué funciones y entornos utilizar para varias tareas de desarrollo comunes.

Tarea	Forma de organización	Seguimiento de origen	Actualizaciones frecuentes	Compatibilidad de vista previa de versión	Todos los metadatos de producción	Metadatos parciales de producción	Conjuntos de datos de gran tamaño desde producción	Conjuntos de datos parciales desde producción	Entornos compatibles
Prototipado	X	X	X	X	X	X		X	Sandboxes de organizaciones borrador, Developer y Developer Pro
Investigaciones de nuevas funciones o desarrollo de pruebas de concepto	X	X	X	X	X	X		X	Sandboxes de organizaciones borrador, Developer y Developer Pro
Pruebas de aceptación de usuarios		X	X	X	X	X		X	Sandboxes de Developer, Developer Pro y Copia parcial
Pruebas de desempeño y escala				X	X		X		Sandbox completo
Formación de usuarios			X	X	X	X	X*	X	Developer Pro, copia parcial y sandboxes completos
*Si es necesario para completar un tipo de trabajo específico, utilice un entorno con menos recursos

Además, tenga en cuenta que para agentes Agentforce que utilizan funciones como la Biblioteca de datos Einstein, artículos Knowledge y datos no estructurados, las pruebas integrales están limitadas a menos que tenga un sandbox de Data 360. También necesita un entorno sandbox de Data 360 para garantizar condiciones de prueba precisas. - **Desvincule entornos de artefactos de versión.** No utilice el [desarrollo basado en](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models) organizaciones. Trate los entornos como lugares donde se realiza el trabajo durante un tiempo fijo. Considere el estado de los metadatos en un entorno como separado de sus artefactos de versión. Si una parte del código o la configuración se “descifra” en un entorno, debe confirmarse con el control de origen, convirtiéndolo en un artefacto de versión. - Los entornos son efímeros. Cree procesos de modo que pueda crearlos y destruirlos lo más rápido posible. - Los artefactos perduran. Pertenecen al control de origen. - **Desvincule entornos de rutas de versión**. Es común ver rutas de versión obligatorias que requieren la implementación de cambios en entornos específicos. A menudo, este enfoque se implementa para establecer un proxy para validar la madurez de la aplicación o la estabilidad de la versión. Los equipos también pueden utilizarlo para intentar minimizar el número de entornos donde deben configurar una infraestructura de pruebas compleja. En paradigmas basados en origen, tiene mayor flexibilidad en cómo y dónde puede validar y probar cambios. - Las etapas de versión se aplican a artefactos de versión, no entornos. No cree un entorno solo con el fin de “recopilar” todos los cambios en una etapa de versión concreta. Para eso está el control de origen, especialmente la bifurcación. Utilice estrategias de bifurcación en el control de origen para organizar qué cambios implementar en qué entornos. Dependiendo del trabajo que necesite realizar, es posible que tenga que implementar todos los metadatos en una versión en un entorno. La bifurcación le permite hacer eso. Con algunas excepciones, cada entorno de desarrollo debe actualizarse o destruirse en cuanto finalice el trabajo relevante. Asegúrese de sincronizar cualquier cambio en metadatos que tenga lugar dentro de un entorno específico (y que desea conservar) con el control de origen. - Los entornos son tan útiles como su fidelidad a la producción. Optimice sus flujos de trabajo de configuración de entornos o automatización de modo que pueda derribar o actualizar entornos lo más rápido posible. Considere cualquier configuración que le impida realizar actualizaciones de entorno más rápidas y frecuentes como un riesgo crítico para la resistencia general de sus procesos de ALM. Si tiene trabajo de corrección relacionado, agréguelo a sus planes y asígnele prioridad. Explore cómo puede adoptar [unidades modulares](/docs/architect/es-mx/well-architected/guide/composable) acopladas de forma más flexible en su sistema. Permiten a los equipos realizar más tipos de desarrollo en organizaciones borrador y liberan asignaciones de sandbox para otro trabajo. No olvide las funciones que las organizaciones borrador proporcionan para funciones de prueba que no tiene en producción, ya sea porque no adquirió licencias para ellas o las activó. - En entornos a los que los usuarios de negocio o usuarios finales pueden acceder, permita a esos usuarios centrarse en lo que les importa. No tenga entornos genéricos no diferenciados donde muchos grupos diferentes de usuarios finales o partes interesadas de negocio intentan realizar trabajo relacionado con ALM. Invite y active partes interesadas específicas en entornos específicos para realizar trabajo específico. Evalúe cuidadosamente cualquier proceso que ponga a los usuarios finales o partes interesadas de negocio en un entorno con más datos de los que admite un entorno sandbox de copia parcial. Asegúrese de que el volumen de datos es necesario para el trabajo que se va a realizar. Planifique sus pruebas de aceptación de usuarios y ciclos de desarrollo de etapa temprana de modo que se produzcan lo más juntos posible. Optimice todas las etapas de prueba para permitir ciclos de iteración y comentarios más rápidos y anteriores para sus equipos de desarrollo y usuarios finales. Consulte [Estrategia de pruebas](/docs/architect/es-mx/well-architected/guide/resilient#estrategia-de-prueba). - **Cree diferentes rutas de versión para diferentes tipos de cambios**. No todos los cambios requieren que se completen los mismos tipos de trabajo de ALM en el mismo orden. Tener usuarios finales realizando pruebas de aceptación para cambios menores en componentes backend de un sistema probablemente no sea un buen uso de su tiempo. Sin embargo, la aceptación de usuarios y las pruebas de escala pueden ser tremendamente valiosas durante la etapa inicial de desarrollo de una aplicación móvil. Identifique rutas de lanzamiento para diferentes categorías de cambios, como riesgo alto, riesgo medio y riesgo bajo. - **Riesgo alto:** Los cambios afectan a clientes, socios o todos los usuarios internos. Los cambios afectan a la seguridad o la integración. Los cambios agregan nuevas funciones complejas. - **Riesgo medio:** Los cambios afectan a más de un umbral definido de usuarios internos. Los cambios afectan a modelos de datos, automatización que realiza operaciones de datos o integración. - **Riesgo bajo:** Afecta directamente a menos de un umbral definido de usuarios internos. No incluye cambios en la seguridad, modelos de datos o automatizaciones que implican operaciones de datos o integración. - **No permita que existan entornos superpoblados**. La falta de disciplina en la priorización, el ámbito y la secuenciación del trabajo conduce inevitablemente a entornos de desarrollo sobrecargados, con volúmenes de trabajo que son demasiados, demasiados, demasiado diferentes. Los entornos superpoblados crean altos niveles de estrés, ambigüedad y conflicto entre los equipos de desarrollo. También crean ruido en las oportunidades en curso de desarrollo e impiden los esfuerzos de control de calidad. Además de estos efectos negativos, los entornos de desarrollo superpoblados son graves amenazas para el mantenimiento y la seguridad del medio ambiente. Considere la masificación como un síntoma de posibles problemas en sus procesos de ALM. Investigue cualquier problema de causa raíz y resuélvalo. Si aún se enfrenta a aglomeraciones, puede [adquirir entornos sandbox adicionales](https://help.salesforce.com/s/articleView?id=sf.data_sandbox_environments.htm&type=5). La lista de [patrones y antipatrones para ALM](/docs/architect/es-mx/well-architected/guide/resilient#patrones-y-antipatrones-de-alm) muestra el aspecto adecuado y deficiente de la gestión del entorno en una organización de Salesforce. Utilícelos para validar sus diseños antes de construir o para identificar áreas de su sistema que necesitan refactorizarse. Para obtener más información acerca de herramientas de Salesforce para la gestión del entorno, consulte [Herramientas de Salesforce para Resiliencia](/docs/architect/es-mx/well-architected/guide/resilient#herramientas-de-salesforce-para-la-resiliencia). ### Estrategia de señalización Una estrategia de señalización define las señales críticas y la instrumentación de aplicación necesaria para detectar, diagnosticar y remediar fallos antes de que se degraden en cascada en todo el sistema. La instrumentación efectiva transforma aplicaciones de víctimas pasivas de fallos en participantes activos en su propia resiliencia, capaces de detectar problemas, adaptar su comportamiento y coordinar la degradación elegante cuando sea necesario. Cuando las aplicaciones implementan instrumentación integral, obtienen la capacidad de autorregularse bajo estrés, comunicar su estado de salud a los operadores y participar en esfuerzos de recuperación coordinados. Estas funciones permiten a los sistemas mantener la calidad del servicio incluso cuando los componentes individuales experimentan dificultades. Por otro lado, sin la instrumentación adecuada, las aplicaciones se convierten en cajas negras que fallan silenciosamente hasta que aparecen síntomas catastróficos. Los equipos reaccionan ante problemas solo después de que los usuarios los reporten, y la solución de problemas se convierte en un ejercicio de arqueología en vez de observación. - **Detecte fallos en la aplicación**. Las aplicaciones deben instrumentarse para detectar y responder a patrones de fallo comunes que surgen bajo carga pesada. Considere la saturación de colas. Cuando las colas de mensajes se rellenan más rápido de lo que se pueden procesar, las aplicaciones no instrumentadas continúan aceptando trabajo hasta que se produzcan el agotamiento de la memoria o cascadas de tiempo de espera. Las aplicaciones correctamente instrumentadas monitorean la profundidad de la cola, los índices de rechazo y la latencia de procesamiento, desencadenando respuestas defensivas cuando se superan los umbrales. - **Gestionar eficazmente señales desde fuera de la aplicación**: La gestión de señales desde el sistema operativo representa otro punto de instrumentación crítico. Las aplicaciones deben registrar controladores para señales de terminación (SIGTERM, SIGINT) para activar el apagado elegante. Durante el apagado, las aplicaciones equipadas correctamente dejan de aceptar nuevo trabajo, permiten que las solicitudes en vuelo se completen, lavan los buffers, cierran conexiones de forma limpia y cancelan el registro del descubrimiento de servicios. Este apagado orquestado evita la pérdida de datos y permite a los equilibradores de carga redirigir el tráfico sin interrupciones. - **Instrumento para escenarios de fallo complejos:** Más allá de estos patrones básicos, las aplicaciones deben instrumentar para modos de fallo más sutiles. La identificación de fallos grises, donde los componentes parecen saludables para algunos observadores mientras fallan para otros, requiere correlacionar señales internas y externas. Una aplicación podría instrumentar su conjunto de conexiones de base de datos para reportar comprobaciones de estado satisfactorias mientras realiza un seguimiento simultáneo de los índices de finalización de transacciones que revelan una degradación progresiva. Las estrategias de instrumentación efectivas cubren múltiples puntos de observación. - Las **mediciones de negocio** realizan un seguimiento de indicadores de éxito específicos de la aplicación, como índices de realización de pedidos o calidad de resultados de búsqueda. - Las **mediciones del sistema** monitorean la utilización de recursos, las distribuciones de latencia y los índices de error. - **Las sondas sintéticas** realizan continuamente rutas críticas para detectar la degradación antes de que los usuarios la encuentren. - **El rastreo distribuido** proporciona visibilidad a nivel de solicitud entre límites de servicio. Estas señales se exponen a través de interfaces estandarizadas que permiten a los sistemas automatizados y operadores humanos evaluar el estado de la aplicación. La instrumentación en sí se convierte en parte de la estrategia de resiliencia de la aplicación, permitiendo a los disyuntores desencadenarse basándose en índices de error, los escaladores automáticos para responder a profundidades de cola y los [operadores para tomar decisiones fundamentadas durante incidentes](/docs/architect/es-mx/well-architected/guide/resilient#respuesta-de-incidente). Los [patrones y antipatrones para ALM](/docs/architect/es-mx/well-architected/guide/resilient#patrones-y-antipatrones-de-alm) muestran el aspecto de una estrategia de señalización adecuada y deficiente en una organización de Salesforce. Utilícelos para validar sus diseños antes de construir o para identificar áreas de su sistema que necesitan refactorizarse. Para obtener más información acerca de herramientas de Salesforce para una estrategia de señalización, consulte [Herramientas de Salesforce para Resiliencia](/docs/architect/es-mx/well-architected/guide/resilient#herramientas-de-salesforce-para-la-resiliencia). ### Estrategia de prueba Una estrategia de prueba es un conjunto de principios rectores y estándares sobre cómo planificar y ejecutar pruebas que miden el éxito y el fallo de las aplicaciones durante los procesos de ALM. Una estrategia de prueba mantiene a todas las partes interesadas que participan en pruebas informadas y alineadas con la prioridad, el propósito y el ámbito de una prueba concreta. También ayuda a los equipos de proyectos a crear planes de prueba efectivos y reflexivos. Normalmente, los desarrolladores o expertos en pruebas y garantía de calidad participan en la creación y ejecución de pruebas específicas. Una estrategia de prueba ayuda a garantizar que estas personas sepan qué tipos de pruebas se deben realizar para un proyecto concreto y en qué secuencia realizarlas. Una estrategia de prueba también ayuda a garantizar que los equipos tienen lo que necesitan para crear pruebas, planes de prueba y artefactos bien formados (por ejemplo, conjuntos de datos de prueba, dispositivos y simuladores de tráfico o red). Una estrategia de pruebas efectiva crea una imagen clara de cómo, cuándo, dónde y por qué ejecutar diferentes tipos de pruebas (incluyendo pruebas de unidad, pruebas de interfaz de usuario y pruebas de regresión) en varias combinaciones y condiciones para descubrir cómo se comportará su sistema y cualquier cambio en vuelo. Una estrategia de prueba efectiva produce pruebas que le muestran cuán bien se ajusta un sistema a requisitos no funcionales, como escalabilidad, fiabilidad y capacidad de uso, que pueden ser difíciles de medir a través de un único tipo de prueba. Para crear estrategias de prueba efectivas para Salesforce: - **Pruebe de forma iterativa, frecuente y automatizada tanto como sea posible**. Diseñe e implemente la automatización de pruebas que permite a los equipos ejecutar una variedad de tipos de pruebas en una variedad de cargas de trabajo. Orqueste varias ejecuciones de prueba para que se produzcan automáticamente cuando los cambios entren en control de origen. Este enfoque permite a los equipos identificar y solucionar regresiones de forma proactiva desde el principio. Utilice integración continua/entrega continua (CI/CD) para este esfuerzo si es posible. Si no lo hace, establezca planes de prueba claros que permitan a los equipos ejecutar secuencias de pruebas de forma temprana y frecuente, de manera autoservicio. Para pruebas de agentes Agentforce, confíe en Centro de pruebas para pruebas rigurosas por lotes de agentes de IA con varias entradas para garantizar que funcionan correctamente en diferentes escenarios. - **Reconozca que no todos los cambios requieren cada tipo de prueba**. Del mismo modo que una canalización de versión efectiva acomoda rutas para aplicaciones de alto, medio y bajo riesgo, también lo hace una estrategia de prueba efectiva. Defina claramente para los equipos cómo seleccionar y seguir un régimen de pruebas apropiado para aplicaciones con varios tipos de riesgo, casos de uso o complejidad. Consulte [Estrategia medioambiental](/docs/architect/es-mx/well-architected/guide/resilient#estrategia-medioambiental). - **Defina qué pruebas se pueden realizar en diferentes tipos de entorno**. La fidelidad a la producción es un componente clave de pruebas precisas, pero significa cosas diferentes para diferentes tipos de pruebas. Por ejemplo, las pruebas de regresión necesitan fidelidad a la producción en términos de metadatos y, en cierta medida, datos. Asegúrese de definir qué tipo de fidelidad a la producción se requiere para un conjunto de pruebas concreto y clasifique claramente qué tipos de entornos pueden admitir las condiciones apropiadas para diferentes pruebas. Para obtener una descripción general de los tipos de trabajo que se alinean con cada tipo de entorno, consulte [Estrategia medioambiental](/docs/architect/es-mx/well-architected/guide/resilient#estrategia-medioambiental). - **Utilice pruebas de resistencia, estrés, desempeño y escala para medir continuamente la madurez de la aplicación**. Estas pruebas muestran cuán lista la versión está una aplicación, en relación con las necesidades a nivel de producción. Para nuevas funciones principales, ejecute estas pruebas en varios intervalos en el ciclo de desarrollo de la aplicación. Es un antipatrón considerar estas pruebas como parte de solo una fase o etapa de desarrollo en vez de como parte de tareas en curso. Es más útil para los equipos obtener comentarios sobre el desempeño de la aplicación de forma temprana y frecuente, lo que les ayuda a comprender mejor lo cerca o lejos que está la aplicación de la preparación a nivel de producción. La capacidad de identificar y solucionar mejor problemas antes de que los cambios entren en producción merece la pena por la complejidad adicional de ejecutar pruebas más sofisticadas con frecuencia. - **Sepa qué pruebas importan**. Probablemente tendrá una cantidad fija de tiempo para realizar sus pruebas de escala o desempeño, haciendo que no sea práctico probar cada aspecto de su sistema. No todas las funciones se utilizan por igual, y no todos los cuellos de botella de escala afectarán al negocio por igual. Asegúrese de que sus pruebas de escala están centradas en las partes más utilizadas y valoradas del sistema. Defina y comprenda las oportunidades más importantes para verificar y mejorar la escala y el desempeño en su organización. - **Sepa el aspecto “suficientemente bueno”.** Definir los criterios de éxito para sus pruebas de escala y desempeño es clave. Asegúrese de que usted y sus equipos de desarrollo utilizan los criterios de éxito como indicadores de prueba. Además, asegúrese de que informan sobre los requisitos funcionales que crean los equipos de desarrollo. Normalmente, estos criterios incluyen la compatibilidad con un número específico de usuarios simultáneos con tiempos de respuesta inferiores a un valor acordado y sus [objetivos de servicio (SLO)](/docs/architect/es-mx/well-architected/guide/resilient#tiempo-de-recuperación). Defina sus criterios de destino clave y luego diseñe pruebas de escala y desempeño que garanticen que se cumplen los criterios. - **Asegúrese de tener entornos adecuados.** Las pruebas de escala y desempeño requieren una fidelidad particular a la producción. Sus conjuntos de datos, datos demográficos de solicitudes, índices de solicitudes y características de carga de trabajo en sus entornos no de producción deben coincidir con lo que ve en producción tanto como sea posible. Para las pruebas de escala, debe utilizar un Sandbox completo. Si su organización no tiene un Sandbox completo para pruebas de escala, no puede ejecutar pruebas de escala adecuadas. - **Asegúrese de que las cargas de trabajo de prueba le ayudan a medir requisitos no funcionales**. Recuerde tener en cuenta: - **Datos de prueba**: Se debe realizar todo tipo de pruebas con datos aislados de la producción. En pruebas de unidades Apex, implemente [patrones de fábrica](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_utility_classes.htm) para garantizar que el código genera sus propios datos de prueba, aislados de datos de entorno. También puede crear y mantener conjuntos de datos de prueba en una variedad de formatos para probar comportamientos de carga de datos, rellenar entornos de desarrollo con datos para pruebas basadas en la interfaz de usuario y ayudar con pruebas de integración. Todos los datos de prueba, ya se mantengan como un conjunto de datos externalizado o se creen on demand por código de fábrica de datos, deben depurarse de datos confidenciales e identificativos. Debe incluir datos dañados, incompletos y mal formados para admitir comportamientos de prueba de unidad negativos y de límite. - **Servicios simulados**: Para pruebas de integración, puede utilizar servicios simulados para simular respuestas de API. Apex admite una [API de código](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_stub_api.htm) auxiliar para crear marcos de trabajo simulados para su uso en pruebas Apex. Simulación para crear marcos de trabajo simulados que se pueden utilizar en pruebas Apex. Las simulaciones y los stubs pueden ayudar a validar comportamientos de tratamiento de datos de un sistema, con menos dependencia de fábricas de datos complejas o conjuntos de datos de prueba externos. Las simulaciones y los stubs son a veces más apropiados para utilizar en pruebas donde el tráfico similar a producción o los volúmenes de datos no son relevantes. - **Dispositivos y tecnología de asistencia**: Una parte clave de la creación de aplicaciones [atractivas](/docs/architect/es-mx/well-architected/guide/engaging) y [accesibles](/docs/architect/es-mx/well-architected/guide/compliant#accesibilidad) es garantizar que cumplen las expectativas de los usuarios entre una variedad de dispositivos y con diferentes tipos de tecnologías de asistencia. Las pruebas de capacidad de uso significativas pueden requerir más inversión y diferentes tipos de experiencia para llevarse a cabo de forma efectiva, pero es una parte esencial de saber cuán bien diseñadas estarán sus aplicaciones de cara al usuario cuando se publiquen. - **Simuladores**: Cuando necesita replicar volúmenes similares a producción de solicitudes de usuario, tráfico de API o variaciones en la velocidad de red, es posible que necesite herramientas que simulen estas condiciones. No todas las pruebas necesitan este nivel de inversión. Estas herramientas son a menudo más útiles en pruebas de escalabilidad y desempeño. - **Pruebas de IA** y agentes: Un objetivo principal de las pruebas es reducir las alucinaciones de IA, que son respuestas convincentes que son fabricadas e incorrectas. Asegúrese de que los casos de uso de IA se prueban para resaltar problemas comunes causados por una comprensión incompleta del cliente, datos que faltan, campos con metadatos incompletos y datos desfasados. Utilice el Centro de pruebas para ayudar con la creación de datos de prueba necesarios para dichas pruebas. ### Patrones y antipatrones de ALM La siguiente tabla muestra una selección de patrones para buscar o crear en su organización, y antipatrones para evitar u objetivo para la corrección. ✨ Descubra más patrones para ALM en el [Explorador de patrones y](/docs/architect/es-mx/well-architected-tools/guide/adaptable-application-lifecycle-management) antipatrones.

	Patrones	Antipatrones
Gestión de versiones	En producción: - Los metadatos muestran el uso de mecanismos de versión estables, como: -- Metadatos organizados en paquetes desbloqueados -- DevOps Center activo e instalado -- Implementaciones a través de la API de metadatos utilizando el formato de origen - Los registros de implementación no muestran implementaciones con fallos en el historial disponible. - El historial de implementación muestra cadencias de versión claras y clústeres de implementación bastante uniformes en plazos de versión.	En producción: - Los metadatos indican el uso de mecanismos de versión basados en organizaciones, como: -- Uso activo de conjuntos de cambios -- Las implementaciones a través de la API de metadatos utilizan el formato package.xml - Los registros de implementación muestran instancias repetidas de implementaciones fallidas en el historial disponible. - Las implementaciones no tienen una cadencia discernible o muestran agrupaciones desiguales de implementaciones, que son signos de soluciones rápidas y reversiones ad hoc). - DevOps Center no está activado e instalado.
Gestión de versiones	En su hoja de ruta y documentación: Los nombres de versión están claros. - Las funciones están claramente vinculadas a una versión nombrada específica. - Los nombres de versión tienen capacidad de búsqueda y descubrimiento. - Los equipos pueden encontrar y seguir directrices claras para etiquetar artefactos, elementos de desarrollo y otro trabajo con los nombres de versión correctos. - Es posible obtener una vista clara de un manifiesto de versión por un nombre de versión. - Los umbrales de calidad para aplicaciones de IA generativa se definen para diferentes etapas de desarrollo.	En su hoja de ruta y documentación: - Los nombres de versión no están incluidos. - Las funciones no están claramente vinculadas a una versión específica. - Los nombres de versión se utilizan ad hoc o no existen. - Los equipos hacen referencia a artefactos, elementos de desarrollo y otros trabajos de diferentes formas. - No es posible obtener una vista clara de un manifiesto de versión utilizando un nombre de versión. - Los umbrales de calidad para aplicaciones de IA generativa no están definidos, o si lo están, no están definidos para diferentes etapas de desarrollo.
Estrategia medioambiental	En sus organizaciones: - Se adopta un modelo de desarrollo y versión dirigido por origen. - El seguimiento de origen está activado para sandboxes Developer y Developer Pro. - Los metadatos en un entorno concreto son independientes de los artefactos de versión. - Los entornos no se corresponden directamente con una ruta de versión. - Las rutas de lanzamiento para un cambio dependen del tipo de cambio (riesgo alto, riesgo medio o riesgo bajo). - Los entornos superpoblados no existen. - Los cambios de configuración arriesgados nunca se realizan directamente en producción. - No se producen liberaciones durante el horario laboral pico. - Los sandboxes de Data 360 se utilizan para probar correctamente casos de uso de agentes que requieren Biblioteca de datos Einstein, artículos Knowledge y datos no estructurados	En sus organizaciones: - Se adopta un modelo de desarrollo y versión basado en organización. - El seguimiento de origen no está activado para sandboxes Developer y Developer Pro. - Los metadatos en un entorno concreto son un artefacto de versión. - Los entornos corresponden directamente a una ruta de versión. - La ruta de liberación para cada cambio es la misma, independientemente del tipo de cambio. - Existen entornos superpoblados. - Los cambios de configuración arriesgados se realizan directamente en producción. - Las liberaciones se producen durante las horas de oficina pico. - Los agentes Agentforce que requieren Biblioteca de datos Einstein, artículos Knowledge y datos no estructurados no se prueban utilizando sandboxes de Data 360
Estrategia de señalización	En sus organizaciones: - Los equipos colaboran en la definición y estandarización de API y SLO de comprobación de estado. El examen periódico y el perfeccionamiento de las estrategias de señalización forman parte de los exámenes post mortem y de la preparación operacional. En producción: - Se implementan comprobaciones de estado para todas las aplicaciones. - Las aplicaciones proporcionan señales explícitas acerca de su estado, como su carga y capacidades. - Las aplicaciones están diseñadas para degradarse con gracia cuando las dependencias no son saludables. - El desprendimiento de carga se utiliza para evitar fallos en cascada. En su diseño: - La contrapresión y los mecanismos de eliminación de carga evitan que los servicios se vean desbordados por el tráfico. Se supone que las dependencias fallan. Los controladores de señales están creados para mejorar los fallos.	En sus organizaciones: - Los equipos operan en silos, creando mecanismos de señalización sanitaria incoherentes e incompatibles. - Las estrategias de señalización son un pensamiento posterior, solo se solucionan cuando se produce un incidente. En producción: - Los componentes fallan silenciosamente sin señalar su estado de salud. - Las solicitudes reintentan solicitudes en servicios no saludables indefinidamente. - Todas las solicitudes son tratadas con la misma prioridad, independientemente de su importancia. - Para identificar problemas, los operadores se basan únicamente en medidas reactivas, como quejas de usuarios o fallos críticos del sistema. En su diseño: - Se supone que todas las dependencias estarán siempre disponibles, y las particiones de red, los picos de latencia u otros problemas comunes no se tienen en cuenta. - Las aplicaciones aceptan todas las solicitudes entrantes, incluso cuando están sobrecargadas, lo que lleva a un aumento de la latencia y una mayor probabilidad de fallo
Estrategia de prueba	En su negocio: - Las pruebas de capacidad de uso emplean una variedad de dispositivos y tecnología de asistencia. - Los simuladores se utilizan para replicar condiciones similares a producción para pruebas de escalabilidad y desempeño. - Las pruebas están automatizadas para ejecutarse cuando los cambios entran en control de origen. - Las pruebas de resistencia, estrés, desempeño y escala se ejecutan en varios intervalos en el ciclo de desarrollo de la aplicación y se consideran tareas en curso. - Incluye pruebas de escala como parte de su proceso de control de calidad cuando tiene aplicaciones a escala B2C, grandes volúmenes de usuarios o grandes volúmenes de datos. - Sus pruebas de escala se centran en aspectos de alta prioridad del sistema. - Sus pruebas de escala tienen criterios bien definidos. - Realiza pruebas de escala en un Sandbox completo. - La ingeniería de solicitudes incluye una revisión de calidad por un humano. - Centro de pruebas de Agentforce se utiliza para pruebas de agentes sólidas.	En su negocio: - Las pruebas de capacidad de uso no se realizan, o si lo son, se realizan en un conjunto limitado de dispositivos. - Los volúmenes similares a producción de solicitudes de usuario, el tráfico de API y las variaciones en la velocidad de red no se prueban. - La automatización de pruebas no está establecida. - Las pruebas de resistencia, estrés, desempeño, escala se consideran una fase o etapa de desarrollo. - No realiza pruebas de escala como parte de su proceso de control de calidad y tiene aplicaciones a escala B2C, grandes volúmenes de usuarios o grandes volúmenes de datos. Sus pruebas de escala no tienen prioridad. - Sus pruebas de escala no tienen criterios bien definidos. - Realiza pruebas de escala en un sandbox de copia parcial o Developer Sandbox. - La ingeniería de solicitudes no incluye una revisión de calidad por un humano. - Los agentes Agentforce no se prueban, o si lo están, solo se prueban ad hoc utilizando Agent Builder.
	En su organización: - Todos los datos de prueba se depuran con datos confidenciales e identificativos.	En su organización: - Los datos de prueba son idénticos a los datos de producción.
	En Apex: - Los patrones de fábrica de datos se utilizan para pruebas de unidades - Las simulaciones y los stubs se utilizan para simular respuestas de API.	En Apex: - Las pruebas de unidad se basan en datos de organización. No se usan simulacros y albaranes.
	En sus estándares de diseño y documentación: - Los entornos se clasifican por los tipos de pruebas que pueden admitir. - Los regímenes de prueba apropiados se especifican según el riesgo, el caso de uso o la complejidad.	En sus estándares de diseño y documentación: - No está claro qué tipos de pruebas admite cada entorno. - Los regímenes de prueba no están categorizados por riesgo, caso de uso o complejidad.

## Respuesta de incidente En ingeniería de seguridad y fiabilidad de sitio (SRE), la respuesta ante incidentes se centra en cómo los equipos identifican y abordan eventos que afectan a la disponibilidad general o la seguridad de un sistema, así como en cómo trabajan los equipos para abordar causas raíz y evitar problemas futuros. La respuesta a incidentes implica los procesos, las herramientas y los comportamientos organizativos requeridos para solucionar problemas en tiempo real y después de que se produzca un problema. Como arquitecto, es posible que no sea la persona que monitoree las operaciones de su solución en el día a día una vez que entre en funcionamiento. Parte de la arquitectura para la resiliencia es el diseño de funciones de recuperación que permiten a los equipos de asistencia realizar diagnósticos de primer nivel, estabilizar sistemas y entregar de forma efectiva la investigación y la mitigación de causas raíz a equipos de desarrollo o mantenimiento. Es posible que los equipos que asisten directamente a los usuarios en el día a día no tengan una comprensión profunda o experiencia en la arquitectura del sistema. Es esencial que estos equipos tengan las herramientas y los procesos que necesitan para monitorear las operaciones diarias, acceder a la información desde el sistema al diagnosticar un posible incidente y servir como primeros intervinientes efectivos para cualquier problema que afecte a la disponibilidad. Puede mejorar el grado de respuesta de los equipos a incidentes en sus soluciones de Salesforce centrándose en su [tiempo de recuperación](/docs/architect/es-mx/well-architected/guide/resilient#tiempo-de-recuperación), [capacidad de triaje](/docs/architect/es-mx/well-architected/guide/resilient#capacidad-de-triaje) y [monitoreo y alerta](/docs/architect/es-mx/well-architected/guide/resilient#monitoreo-y-alerta). ### Tiempo de recuperación Cuando se produce un incidente, la primera prioridad debe ser restaurar los sistemas a un estado operativo estable. A menudo, los negocios piensan que la única forma de recuperarse de un incidente es “solucionar el problema”. Este supuesto es justo en que el análisis de causa raíz preciso y la solución es la forma en que resuelve problemas críticos en un sistema. Sin embargo, “solucionar el problema” durante las primeras etapas de la respuesta a la crisis no es el enfoque más práctico. Dependiendo de la gravedad de un incidente, cada segundo de este y su repercusión podría llevar a una pérdida de ingresos o reputación para el negocio. A menudo, intentar diagnosticar y solucionar la raíz retrasa los esfuerzos para restaurar un sistema a funcionamiento. Logísticamente, la adopción de un enfoque que solicita a los respondedores de incidentes que aborden las causas profundas ejerce una enorme presión sobre los expertos en la materia (SME) y el personal de asistencia de su compañía. Trabajar para encontrar y solucionar causas raíz _durante_ un incidente requiere que las PYME estén a la espera de cada incidente, lo que puede impedir que el personal de atención al cliente actúe en primera línea. También puede dar como resultado que los equipos publiquen cambios que, a su vez, creen más incidentes. En última instancia, un enfoque de este tipo aumenta los costos, consume ancho de banda entre equipos y lleva a comportamientos en tiempos de crisis que pueden erosionar la Trust del cliente y la reputación de la marca. El paradigma de gestión de incidentes correcto es priorizar y centrarse en la recuperación como un primer paso. Después de restaurar la estabilidad de un sistema, puede realizar un seguimiento con autopsias irreprochables, investigaciones de incidentes, corrección de causas raíz y actividades similares. Este orden de operaciones permite mejor al personal de respuesta ante incidentes clasificar, diagnosticar y ejecutar tácticas de recuperación, alertando a las PYME relevantes para que ayuden solo cuando sea necesario. También permite a las PYME identificar y solucionar las causas profundas de un incidente con menos presión de un reloj automático. Para adoptar una mentalidad de recuperación en primer lugar a la respuesta ante incidentes: - **Establezca y alcance objetivos de nivel de servicio SLO**. Los SLO son estándares que desarrolla con sus partes interesadas para requisitos no funcionales específicos (NFR) de un sistema, como desempeño o tiempo de disponibilidad. Estos objetivos se miden por indicadores de nivel de servicio (SLI), durante un periodo de tiempo. Sin los SLO, gran parte del trabajo relacionado con la respuesta a incidentes y la solución de problemas complejos puede parecer desorganizado y reactivo, por ejemplo, lo que provoca una acción rápida para “detener este error específico, para este puñado de usuarios que lo reportaron”. Este ciclo es a menudo lo que provoca que los equipos acerquen el análisis de causa raíz a la respuesta ante incidentes, ya que parece que ayudará a detener los comportamientos reactivos. Establecer SLO e SLI es una forma más efectiva de empezar. Para establecer SLO, piense en estas preguntas. - **¿Cuáles son los NFR de su sistema para los próximos 1-3 años?** Por ejemplo, su NFR puede incluir los tiempos de respuesta, los índices de solicitudes máximos y los usuarios simultáneos que su sistema debe poder admitir. - **¿Qué desea que experimenten sus clientes y sus usuarios?** Base sus SLO en la respuesta a esta pregunta, que podría ser: “Los usuarios pueden ejecutar reportes rápidamente en Salesforce”. - **¿Qué puede medir y durante qué periodo de tiempo debe medirlo?** Base sus SLI en la respuesta a esta pregunta. Una SLI que coincida con el ejemplo anterior podría ser “_x_ % de la carga de reportes en _n_ segundos de media, medida en un periodo de 30 días”. - **Defina y estandarice tácticas de recuperación.** Las reversiones de cambios y las implementaciones de soluciones pueden ayudar a que un sistema vuelva a funcionar y minimizar la repercusión de un incidente. Tácticas y protocolos de recuperación de documentos que pueden ejecutar los miembros apropiados de sus equipos de asistencia u operaciones. Las tácticas de recuperación varían en función del tipo de incidente. La siguiente tabla muestra un marco general que asigna tipos de incidentes a tácticas de recuperación. Para obtener más información sobre la identificación de puntos de fallo y la definición de estrategias de mitigación, consulte [Disponibilidad](/docs/architect/es-mx/well-architected/guide/reliable#disponibilidad).

Tipo de incidente	Desencadenador aparente	Tácticas de recuperación
Apagones del sistema	Inicios de sesión dañados o problemas con el acceso a la cuenta	Una política de recuperación de cuentas
Apagones del sistema	Indisponibilidad de servicio	Activación de servicio de copia de seguridad redundante; soluciones manuales
Bug de producción	Un cambio reciente	Reversión de implementación o implementación de la versión anterior
Bug de producción	Un fallo emergente e inexplicable	Soluciones manuales, desactivación de funciones no esenciales, distribución a PYME

- **Defina criterios de salida** claros. Utilice sus SLO para determinar cuándo su sistema está fuera del estado de incidente o impacto. - **Defina procesos para revisiones posteriores a incidentes y la solución de causas raíz.** Tómese su tiempo para revisar incidentes después de restaurar el servicio. Durante las revisiones, adopte un enfoque _post mortem sin culpa_. Trabaje con las partes interesadas para centrarse en establecer hechos claros sobre _lo que_ ocurrió y _cómo_ ocurrió, en vez de intentar asignar fallos o culpas a individuos. Utilice diferentes formatos de revisión para examinar formas de solucionar problemas a largo plazo. - Una _revisión posterior_ se centra en la respuesta al incidente. Es útil para evaluar si existen los procesos y las tácticas de respuesta apropiados. - Un _análisis de causa_ se centra en la causa raíz del incidente. Puede ayudar a identificar cualquier fallo o problema en el diseño e implementación de su sistema que condujo al incidente. - **Practique sus protocolos de recuperación acordados periódicamente**. Practique protocolos de recuperación para asegurarse de que todos saben cómo gestionar bien los incidentes. Utilice entornos sandbox y de prueba para proporcionar a los equipos lugares para practicar la simulación y recuperación de incidentes. Practique también sus revisiones posteriores al incidente. Hacer toda esa práctica hace que la recuperación forme parte de su cultura de ingeniería y asistencia. Los [patrones y antipatrones para respuesta ante incidentes](/docs/architect/es-mx/well-architected/guide/resilient#patrones-de-respuesta-ante-incidentes-y-antipatrones) muestran el aspecto de la arquitectura para priorizar la recuperación en una solución de Salesforce. Utilícelos para validar sus diseños antes de construir o para identificar áreas de su sistema que necesitan refactorizarse. Para obtener más información acerca de herramientas de Salesforce para ayudar con el tiempo de recuperación, consulte [Herramientas de Salesforce para Resiliencia](/docs/architect/es-mx/well-architected/guide/resilient#herramientas-de-salesforce-para-la-resiliencia). ### Capacidad de triaje En el contexto de la tecnología, la clasificación implica la asignación de categorías y niveles de gravedad a problemas y solicitudes de asistencia. No importa cuán bien planificada esté su solución, surgirán problemas y solicitudes de asistencia al usuario. Estos problemas pueden deberse a una falta de capacitación suficiente o gestión de cambios, brechas en la interfaz de usuario/UX, comportamientos inesperados del usuario final y problemas urgentes del sistema no detectados por el [monitoreo o alerta](/docs/architect/es-mx/well-architected/guide/resilient#monitoreo-y-alerta). Los equipos de asistencia y operaciones necesitan poder investigar consultas de asistencia de usuarios de forma eficiente y diagnosticarlas rápidamente. Triplicar problemas para filtrar problemas menos graves y detectar rápidamente incidentes críticos del sistema es una competencia clave para estos equipos. La mala clasificación ralentiza todos los niveles de asistencia al usuario, prolonga incidentes críticos y aumenta el riesgo de más interrupciones para sus clientes y su negocio. Aunque es posible que no esté involucrado en operaciones y asistencia diarias, como arquitecto, es su responsabilidad ayudar a garantizar que su equipo de asistencia y operaciones pueda clasificar problemas de forma efectiva en cualquier solución que cree en Salesforce Platform. Para permitir a los equipos clasificar problemas de forma efectiva en sus soluciones de Salesforce: - **Asegúrese de que los equipos de asistencia tienen acceso a información útil**. - **Documente su sistema y diseñe patrones**. Garantizar la [legibilidad](/docs/architect/es-mx/well-architected/guide/intentional#legibilidad) y la coherencia en su solución es una parte clave para permitir al personal de asistencia comprender el sistema que es responsable de dar cobertura. En su documentación, considere cómo los equipos encontrarán información acerca de cómo priorizar problemas o incidentes con diferentes partes del sistema. Además, asegúrese de que los equipos pueden obtener rápidamente información técnica sobre tácticas de recuperación basándose en el área de impacto. Proporcione guías de solución de problemas relevantes para problemas comunes de Agentforce, como Clasificación de temas y Selección de acciones, que pueden ayudar a los equipos a clasificar rápidamente problemas relacionados con permisos o configuración. - **Diseño pensando en depurar**. Los equipos de asistencia y los administradores de la organización tendrán que activar la depuración y el diagnóstico para clasificar correctamente problemas de usuarios en varios entornos. Algunos ejemplos de patrones _depurativos_ incluyen aquellos que incorporan mensajes de error personalizados y de registro en rutas de ejecución en todo el sistema. Active equipos de asistencia en enfoques de depuración comunes Agentforce con herramientas como registros de eventos y la vista de razonamiento de Agent Builder. - **Identifique las PYME y las partes** interesadas de incidentes. Cree una lista de pymes o partes interesadas relevantes que deben estar disponibles para respaldar la recuperación de un incidente y que deben participar durante el análisis posterior al incidente. - **Trata las transferencias cuidadosamente**. Garantice la calidad de cada traspaso de solución a equipos de asistencia u operaciones como parte del lanzamiento. Proporcione capacitación para que el personal de asistencia recorra la arquitectura del sistema relevante y simulacros de respuesta ante incidentes. Piense en transferencias posteriores a incidentes, incluyendo cómo los equipos deben documentar información que no está capturada por registros o notas de casos, así como cómo los respondedores de incidentes pueden contribuir a investigaciones de causas raíz o realizar pruebas de aceptación de usuarios para cualquier corrección. - **Si se le consulta, mantenga a todos centrados en la recuperación como la principal preocupación**. - **Responde rápido.** Responda rápidamente a cualquier solicitud de asistencia de usuario, notificaciones de monitoreo y alertas que reciba. - **Ayude a distinguir síntomas de problemas.** Trabaje para determinar si hay un incidente del sistema real que se debe solucionar. Intente identificar los componentes con los problemas reales. Ayude a garantizar que se siguen las [tácticas de recuperación](/docs/architect/es-mx/well-architected/guide/resilient#tiempo-de-recuperación) acordadas para sacar el sistema del estado de incidente rápidamente. - Para agentes Agentforce admitiendo casos de uso críticos, asegúrese de que existen soluciones viables y relevantes y que se pueden activar con poca antelación como una medida de redundancia. Algunos ejemplos incluyen el cambio a la gestión manual o el redireccionamiento a documentación relevante para su revisión manual. Los [patrones y antipatrones para respuestas ante incidentes](/docs/architect/es-mx/well-architected/guide/resilient#patrones-de-respuesta-ante-incidentes-y-antipatrones) muestran el aspecto de la arquitectura para la clasificación efectiva en una solución de Salesforce. Utilícelos para validar sus diseños antes de construir o para identificar áreas de su sistema que necesitan refactorizarse. Para obtener más información acerca de herramientas de Salesforce para ayudar con el triaje, consulte [Herramientas de Salesforce para Resiliencia](/docs/architect/es-mx/well-architected/guide/resilient#herramientas-de-salesforce-para-la-resiliencia). ### Monitoreo y alerta _Monitoreo_ y _alerta_ son términos ampliamente utilizados en ingeniería de fiabilidad de sitios. En el contexto de la resiliencia del sistema, el monitoreo evalúa continuamente el estado actual de un sistema, y la alerta automatiza las notificaciones a las partes interesadas sobre posibles preocupaciones acerca del estado del sistema. El monitoreo y la alerta efectivos son una parte clave para desvincular la escala y el crecimiento de su sistema de la escala y el crecimiento de su personal de asistencia. Salesforce proporciona una variedad de funciones integradas para monitorear comportamientos en su sistema. Salesforce también ofrece [monitoreo de eventos](https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/real_time_event_monitoring_overview.htm) en tiempo real como complemento o como parte de [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/). En cualquier solución de Salesforce, los diseños diseñados para el monitoreo y la alerta proporcionan: - Funciones para la respuesta ante incidentes automatizada - Información relevante para los usuarios correctos, en el momento correcto - Información clara para vistas históricas y análisis de tendencias Para diseñar un monitoreo y alertas efectivos en sus soluciones de Salesforce: - **Haga de la automatización una prioridad**. Aunque notificar a los usuarios sobre cambios de estado críticos es una parte crucial para mantener sus sistemas estables y operativos, en una arquitectura ideal, el sistema autocorrige problemas cuando es posible y solo envía alertas para problemas urgentes no recuperables. Incluso sin funciones de autocorrección, la automatización puede hacer que sus alertas y reportes sean más útiles. - **Comience con lo que Salesforce ya proporciona**. Salesforce Platform proporciona registros y API relevantes para que monitoree las operaciones de su solución con respecto a los límites reguladores. Además, la plataforma envía alertas para infracciones de límites reguladores y problemas similares. Utilice estos registros y alertas como la base para explorar formas de automatizar más completamente la recuperación automática del sistema, la creación de reportes de incidentes y alertas. Por ejemplo, puede implementar una automatización que monitoree el registro y luego realice una acción de recuperación cuando se registre un tipo de evento concreto. - **Clasifique los cambios en el estado del sistema de formas predecibles**. Cree categorías específicas con sentido para estados clave sobre los que desea monitorear y crear reportes. Alinee estas categorías con las categorías que define para gestionar el estado en sus [componentes de aplicación](/docs/architect/es-mx/well-architected/guide/composable#gestión-de-estado). Adopte una mentalidad [orientada a API](/docs/architect/es-mx/well-architected/guide/composable#gestión-de-api) para el modo en que gestiona la información de cambios de estado. Los formatos de mensajes coherentes y las categorías de estado simplifican la automatización, la creación de reportes y las alertas. - **Alinee su lógica de automatización con las otras partes de su sistema**. Si creó un [tratamiento de errores](/docs/architect/es-mx/well-architected/guide/automated#tratamiento-de-errores) de automatización adecuado, puede ampliar esos patrones a cómo clasifica los cambios de estado y responder con automatización. Para cambios de estado que se consideran recuperables, puede automatizar comportamientos de reintento. Para cambios de estado que se consideran críticos o fatales, automatice alertas a usuarios. - **Evite crear ruido**. Cuando los usuarios reciben demasiadas alertas, especialmente alertas que no requieren realizar ninguna acción, tienden a empezar a desactivar o ignorar todas las alertas. Este escenario socava cualquier esfuerzo para crear alertas [útiles](/docs/architect/es-mx/well-architected/guide/engaging#útil). Para definir mejor quién recibe alertas, qué las desencadena y cuándo se desencadenan, considere hacer estas cosas. - **Cree mapas de partes** interesadas. Para asegurarse de que su sistema entrega las alertas correctas a las partes interesadas correctas en el momento correcto, primero identifique y clasifique sus grupos de partes interesadas. - **Enrute mensajes basándose en privilegios de usuario**. Solo envíe alertas a destinatarios que tengan la capacidad y la autoridad de responder. Los usuarios de negocio podrían beneficiarse de alertas sobre problemas que pueden solucionar corrigiendo problemas en registros a los que tienen acceso. Si un problema requiere una respuesta técnica más implicada, las alertas deben dirigirse al personal de asistencia. - **Deje clara la respuesta esperada**. Solo envíe alertas en escenarios que requieren intervención humana. Estructure mensajes para indicar claramente la acción que se espera del destinatario. Si envía una alerta a una parte interesada para su visibilidad, y no se requiere ninguna acción de su parte, déjelo claro en la versión del mensaje que recibe. - **Haga que las alertas sean oportunas y relevantes**. Las alertas que se entregan en respuesta a fallos que se produjeron y que aún necesitan remediarse no son tan útiles como las alertas sobre un posible fallo. Idealmente, se alerta al personal de asistencia en cuanto se producen condiciones problemáticas en el sistema, proporcionando una oportunidad para [detectar](/docs/architect/es-mx/well-architected/guide/resilient#capacidad-de-triaje) problemas antes de que puedan tener repercusiones negativas en las operaciones de negocio. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/resilient#patrones-de-respuesta-ante-incidentes-y-antipatrones) muestra el aspecto de la arquitectura para un monitoreo y alerta efectivos en una solución de Salesforce. Utilícelos para validar sus diseños antes de construir o para identificar áreas de su sistema que necesitan refactorizarse. Para obtener más información acerca de las herramientas de Salesforce para el monitoreo y la alerta, consulte [Herramientas de Salesforce para Resiliencia](/docs/architect/es-mx/well-architected/guide/resilient#herramientas-de-salesforce-para-la-resiliencia). ### Patrones de respuesta ante incidentes y antipatrones Esta tabla muestra una selección de patrones para buscar o crear en su organización, y antipatrones para evitar o dirigir para su corrección. ✨ Descubra más patrones para la respuesta ante incidentes en el [Explorador de patrones](/docs/architect/es-mx/well-architected-tools/guide/adaptable-incident-response) y antipatrones.

	Patrones	Antipatrones
Tiempo de recuperación	En su negocio: - Los protocolos de recuperación se practican a intervalos regulares. - Los equipos saben de qué servicios en producción son propietarios y responsables. - Los equipos comprenden herramientas relevantes para apoyar el diagnóstico de problemas.	En su negocio: - Los protocolos de recuperación no existen o no se practican a intervalos regulares. - No está claro qué equipos poseen y son responsables de los diferentes servicios en producción. - Los equipos no tienen directrices o estándares sobre herramientas para apoyar el diagnóstico de problemas.
	En su documentación: - Las tácticas de recuperación se definen y clasifican por tipo de incidente y desencadenador. - Los criterios de salida para respuestas de incidentes están incluidos en los SLO y son claros. - Los criterios de activación y la lógica de asignación para permisos elevados durante incidentes son claros. - Los conjuntos de permisos y autorizaciones de respuesta ante incidentes se muestran claramente. - Existe una guía de solución de problemas para ayudar con la identificación y el diagnóstico de problemas comunes.	En su documentación: - La respuesta al incidente se realiza ad hoc. - Los criterios de salida para respuestas de incidentes no existen. - Los permisos elevados no están asignados, o si lo están, están asignados ad hoc. - Los conjuntos de permisos y autorizaciones de respuesta ante incidentes no se muestran.
	En su organización: - Los conjuntos de permisos basados en sesión para la respuesta ante incidentes existen y se pueden asignar al personal de asistencia durante la recuperación. - Configuración del seguimiento de auditoría muestra que los probadores de recuperación designados iniciaron sesión en el entorno de pruebas a la hora acordada y siguieron secuencias de comandos de pruebas de recuperación.	En su organización: - Los conjuntos de permisos basados en sesión no existen para la respuesta ante incidentes, o si lo hacen, el personal de asistencia no está autorizado para utilizarlos. - Configuración Seguimiento de auditoría muestra que los probadores de recuperación designados no iniciaron sesión en el entorno de pruebas o no siguieron secuencias de comandos de pruebas de recuperación
	En sus planes de prueba: - Las secuencias de comandos de prueba para pruebas de recuperación existen y son repetibles. - Los entornos para simulaciones de incidentes están claramente enumerados.	En sus planes de prueba: - Las secuencias de comandos de prueba para pruebas de recuperación no existen. - Los entornos para simulaciones de incidentes no están establecidos.
Capacidad de Triage	En su negocio: – Las PYME o partes interesadas a las que se debe alertar para que presten apoyo a cuestiones complejas se identifican antes de que se produzca un incidente. - La transferencia entre equipos de entrega y asistencia forma parte del lanzamiento. - Si se le consulta, los arquitectos de Salesforce responden rápidamente y ayudan al equipo a permanecer centrado en la recuperación.	En su negocio: - Las PYME o partes interesadas que deben ser alertadas no se identifican hasta que se produzca un incidente. - La transferencia entre equipos de entrega y equipos de asistencia no forma parte del proceso de versión. - Los arquitectos de Salesforce consideran que la respuesta ante incidentes está fuera de su ámbito de trabajo.
	En su documentación: - Los patrones de diseño y sistema utilizados en una solución concreta son detectables y legibles por el personal de asistencia.	En su documentación: - Los patrones de diseño y sistema utilizados en una solución concreta no están disponibles para el personal de asistencia.
	En su organización: - El registro y los mensajes de error personalizados se incorporan en rutas de ejecución en todo el sistema.	En su organización: - El registro y los mensajes de error personalizados no se utilizan.
Monitoreo y alerta	En su organización: - Las alertas solo se utilizan para informar a los usuarios de escenarios que requieren intervención humana; otros fallos se registran y se notifican. - Las alertas se envían a usuarios capaces de responder a ellas. - Cuando sea posible, las alertas se entregan antes de un posible fallo.	En su organización: - Las alertas se envían cuando se produce cualquier tipo de fallo, independientemente de si se requieren acciones de seguimiento. - Las alertas sobre problemas que requieren soluciones técnicas se entregan a usuarios de negocio. - Las alertas solo se entregan en respuesta a fallos que ya se produjeron.
Monitoreo y alerta	En su documentación: - Los criterios de entrada para alertas de ajuste de solicitudes se definen basándose en mediciones de comentarios de IA generativa directa e indirecta.	En su documentación: - No hay criterios definidos para desencadenar alertas de ajuste de solicitudes para aplicaciones de IA generativa.

## Planificación de continuidad Una clave para la resiliencia del negocio es la planificación de la continuidad, que se centra en cómo permitir que las personas y los sistemas funcionen a través de problemas causados por un evento no planificado. Los planes de continuidad de negocio (BCP) tienen una visión orientada a las personas de cómo mantener los procesos avanzando a través de la crisis. Los aspectos técnicos de la planificación de la continuidad figuran en las partes de recuperación en casos de desastre de un BCP. Consulte [Continuidad de tecnología](/docs/architect/es-mx/well-architected/guide/resilient#continuidad-de-la-tecnología). Sin planes de continuidad adecuados, su organización podría ahora saber cómo actuar (y por lo tanto no actuar en absoluto) durante una crisis o un fallo del sistema. La planificación de continuidad ineficaz puede tener un impacto catastrófico en clientes, partes interesadas y negocio. Tras un evento adverso, cada momento que pasa sin mantener o recuperar procesos críticos corre el riesgo de sufrir daños financieros, daños a la reputación, la seguridad de los empleados e incluso el cumplimiento normativo. Puede crear una mejor planificación de continuidad en sus sistemas centrando sus esfuerzos en tres áreas: [definir la continuidad de negocio para Salesforce](/docs/architect/es-mx/well-architected/guide/resilient#continuidad-de-negocio), [planificar la continuidad](/docs/architect/es-mx/well-architected/guide/resilient#continuidad-de-la-tecnología) de la tecnología y [crear funciones de](/docs/architect/es-mx/well-architected/guide/resilient#creación-de-funciones-de-copia-de-seguridad-y-restauración) copia de seguridad y restauración. ### Continuidad de negocio Es posible que su compañía ya tenga un BCP establecido. Si es así, asegúrese de que Salesforce está incluido en él. Si su compañía no tiene un BCP, trabaje con sus partes interesadas para crear uno que cubra sus organizaciones de Salesforce. A menudo se confía en Salesforce para que sea una fuente de verdad para datos de clientes y procesos de negocio esenciales entre muchas divisiones de negocio. Como tal, la función que desempeña Salesforce en un BCP puede diferir de las funciones que desempeñan otros sistemas. Es probable que Salesforce participe en muchas áreas de alta prioridad para la recuperación. Para crear una planificación de continuidad de negocio relevante para sistemas de Salesforce: - **Aclare prioridades para recuperación**. Al igual que con el enfoque general para la [respuesta ante incidentes](/docs/architect/es-mx/well-architected/guide/resilient#respuesta-de-incidente), la recuperación debe ser la primera prioridad para los sistemas en momentos de crisis. Muchos servicios clave de negocio se ejecutan en y con Salesforce. Debe ayudar a las partes interesadas a identificar la prioridad correcta para recuperar varias funciones y capacidades de negocio. Un marco general podría ser: - Estabilice la infraestructura de negocio esencial. - Estabilice los servicios al cliente. - Estabilice los servicios de empleados y socios. - **Tenga en cuenta su ecosistema en sus BCP**. Salesforce no es el único sistema en su panorama. Asegúrese de identificar brechas en su BCP alrededor de sistemas que se integran con Salesforce, soluciones instaladas desde proveedores AppExchange y cualquier otro sistema que se conecta a datos o procesos en Salesforce. Si su capacidad de entrega depende de proveedores, pregunte a esos proveedores acerca de sus planes de continuidad. Evalúe sus funciones y planifique cómo mantener sus sistemas disponibles. - **Integre las preocupaciones de BCP en su estrategia de pruebas**. Cree planes de prueba para su BCP y llévelos a cabo. Es especialmente importante probar las áreas de su BCP relacionadas con procesos o personas, que a menudo se pasan por alto. Incorpore elementos relevantes de su BCP en su [estrategia de prueba](/docs/architect/es-mx/well-architected/guide/resilient#estrategia-de-prueba) de ALM general. Cree y siga una programación de mantenimiento para revisar pruebas y asegurarse de que su plan se mantiene actualizado. Los [patrones y antipatrones para planificación de continuidad](/docs/architect/es-mx/well-architected/guide/resilient#patrones-y-antipatrones-de-planificación-de-la-continuidad) muestran el aspecto adecuado y deficiente de la planificación de continuidad en una solución de Salesforce. Utilícelos para validar sus diseños antes de construir, o para identificar lugares en su sistema que necesitan refactorizarse. Para obtener más información acerca de las herramientas de Salesforce para definir la continuidad del negocio, consulte [Herramientas de Salesforce para Resiliencia](/docs/architect/es-mx/well-architected/guide/resilient#herramientas-de-salesforce-para-la-resiliencia). ### Continuidad de la tecnología El objetivo de la continuidad de la tecnología es asegurarse de que los problemas con componentes en un sistema no impiden que el negocio mantenga operaciones esenciales. Salesforce prioriza el mantenimiento de nuestros servicios en los niveles más altos de disponibilidad y la provisión de información transparente sobre cualquier problema. Puede ver información en tiempo real sobre el desempeño del sistema de Salesforce y problemas en [trust.salesforce.com](https://trust.salesforce.com/). Como arquitecto que construye en Salesforce, sus soluciones se benefician de las funciones de fiabilidad, seguridad y desempeño del sitio que Salesforce proporciona en toda la plataforma. Sin embargo, la continuidad general de sus soluciones de Salesforce va más allá de los servicios integrados que proporciona Salesforce. Desde una perspectiva arquitectónica, la planificación de la continuidad de la tecnología de Salesforce debe comenzar con la formulación y respuesta de preguntas acerca de cómo se ajusta Salesforce a su panorama de negocio más amplio. ¿Qué tipos de sistemas se integran con Salesforce? ¿Cómo dependen los sistemas externos de procesos o información en Salesforce? En sus organizaciones de Salesforce, ¿qué procesos o funciones se basan en soluciones AppExchange? ¿Acceden sus usuarios a Salesforce a través de servicios de identidad externos o SSO? Para crear una mejor continuidad de la tecnología en sus sistemas de Salesforce: - **Evalúe su infraestructura.** La estrategia de solución más común para problemas o interrupciones de la tecnología es crear servicios o sistemas redundantes a los que puede recurrir durante un incidente. En Salesforce, tenemos una arquitectura intencionadamente redundante, lo que significa que mantenemos copias de los sistemas y servicios de nuestros clientes en diferentes ubicaciones físicas. Utilizamos varias técnicas de recuperación de desastres, incluyendo el cambio de sitio, que nos permite dirigir el tráfico de usuarios de un centro de datos a otro si es necesario. Para identificar dónde podría necesitar crear redundancia intencionada, hágase estas preguntas. - ¿Qué sucede durante una interrupción del servicio para el servicio \[X]? ¿Podemos cambiar de ese servicio a otro? - ¿Cuánto tarda en recuperarse \[X]? ¿Cuál es el impacto para nuestros clientes? ¿Cuál es el impacto para nuestros socios? ¿Cuál es la repercusión en los equipos internos? - ¿Qué hay de las [copias de seguridad](/docs/architect/es-mx/well-architected/guide/resilient#creación-de-funciones-de-copia-de-seguridad-y-restauración) y su frecuencia? ¿Podrían las copias de seguridad proporcionar los datos necesarios para dar cobertura al negocio? - ¿Tenemos dependencias de proveedores? ¿Cuáles son sus planes de BCP? - **Proporcione asistencia operativa.** La asistencia operativa consiste en poner los equipos en marcha lo más rápido posible. Piense en cómo su sistema puede gestionar aumentos significativos en requisitos de capacidad y demanda de cambios imprevistos, incluyendo cambios que son de toda la industria, de toda la región o globales. Asegúrese de que su BCP tiene en cuenta los recursos adicionales o los procedimientos de ruptura que Ingeniería de fiabilidad de sitio (SRE) o los equipos de asistencia pueden necesitar para responder a incidentes de forma efectiva. Las preguntas que se deben formular acerca de la asistencia operativa incluyen: - En caso de fallo, ¿dispondrían nuestros equipos técnicos de las herramientas que necesitan para continuar trabajando? ¿Hemos simulado una interrupción para validar planes o identificar brechas? - Si un desastre está en un área específica, ¿tenemos planes de cobertura para esa área? - ¿Son nuestros clientes globales? ¿Funcionan 24/7? - ¿Tenemos [monitoreo y alerta](/docs/architect/es-mx/well-architected/guide/resilient#monitoreo-y-alerta) apropiados para notificar a las personas apropiadas cuando hay fallos? - **Automatice y pruebe sus tácticas de recuperación.** Después de solucionar un problema, identifique dónde se produjo y cómo se solucionó. Si puede, basándose en la solución, automatice sus tácticas de recuperación y ajuste cualquier problema de proceso. Muchas compañías programan simulaciones de incidentes para un subconjunto de servicios para probar la resistencia del sistema. Un ejemplo podría ser simular una cuenta de administrador del sistema bloqueada o comprometida, o simular una interrupción o un problema con un proveedor AppExchange. Consulte [Respuesta a incidentes](/docs/architect/es-mx/well-architected/guide/resilient#respuesta-de-incidente).)Las preguntas que hay que formular acerca de cómo las pruebas y la automatización pueden ayudarle a restaurar servicios con mayor rapidez incluyen: - ¿Con qué frecuencia programamos y ejecutamos simulaciones de incidentes? - ¿Sabemos cuánto tarda en restaurar los servicios a un estado estable? - ¿Tenemos procesos de entrega estables? - ¿Sabemos dónde podemos automatizar la conmutación por error y la recuperación? Trate cualquier elemento que surja de sus revisiones posteriores al incidente como sus otros elementos de desarrollo. Agréguelos a sus sistemas de planificación de modo que pueda priorizarlos y trabajar en ellos. Los [patrones y antipatrones para planificación de continuidad](/docs/architect/es-mx/well-architected/guide/resilient#patrones-y-antipatrones-de-planificación-de-la-continuidad) muestran el aspecto adecuado y deficiente de la planificación de continuidad de la tecnología en una solución de Salesforce. Utilícelos para validar sus diseños antes de construir, o para identificar lugares en su sistema que necesitan refactorizarse. Para obtener más información acerca de herramientas de Salesforce para la planificación de la continuidad de la tecnología, consulte [Herramientas de Salesforce para Resiliencia](/docs/architect/es-mx/well-architected/guide/resilient#herramientas-de-salesforce-para-la-resiliencia). ### Creación de funciones de copia de seguridad y restauración La restauración de copias de seguridad de datos o metadatos puede ayudar a devolver su organización a su último estado estable conocido. También puede proporcionar un sistema de conmutación por error durante un fallo catastrófico del sistema o una interrupción del servicio. Realizar copias de seguridad de sus datos y metadatos regularmente y almacenar sus copias de seguridad cifradas en una ubicación segura agrega una capa adicional de resistencia a su arquitectura. Sin estrategias de copia de seguridad y restauración, no puede restaurar versiones limpias de sus datos y metadatos de producción cuando se corrompen maliciosamente, cuando los defectos se abren paso inadvertidamente en producción o cuando un fallo durante una gran carga de datos corrompe los datos de producción. Cualquiera de estos escenarios puede dar como resultado que sus datos de producción críticos de negocio se corrompan o incluso se pierdan de forma permanente. La configuración de la tecnología de copia de seguridad y restauración ofrece una serie de ventajas además de la planificación de continuidad, incluyendo la asistencia con estrategias para mitigar grandes volúmenes de datos y cumplir con políticas de retención relacionadas con el cumplimiento. Para ayudar a garantizar la continuidad con las estrategias de copia de seguridad y restauración en sus soluciones de Salesforce: - **Empiece.** El primer paso para tener una buena estrategia de copia de seguridad y restauración es tener una estrategia en primer lugar. Incluso algo tan sencillo como realizar copias de seguridad nocturnas de todos los datos y metadatos de su organización puede ahorrar a su negocio la pérdida de información o funciones críticas durante un desastre. - **Restrinja el acceso a copias de seguridad.** Los administradores del sistema son los únicos usuarios que deben tener acceso a copias de seguridad de sus datos. Esa restricción de acceso evita que un usuario de negocio pueda ver registros en una copia de seguridad que no estaría autorizado a ver en su organización. - **Pruebe su proceso de restauración regularmente.** Independientemente de la estrategia de copia de seguridad y restauración que implemente, [pruebe](/docs/architect/es-mx/well-architected/guide/resilient#estrategia-de-prueba) su proceso de restauración en un entorno sandbox de copia parcial o completa regularmente para asegurarse de que funcionará correctamente cuando lo necesite. - **Alinee su estrategia de copia de seguridad y restauración con su estrategia de archivo de datos.** Determine qué debe suceder en sus copias de seguridad o archivos cuando se archivan o purgan registros de su sistema. Consulte [Volumen de datos](/docs/architect/es-mx/well-architected/guide/reliable#volumen-de-datos)). Es posible que necesite una estrategia de copia de seguridad más granular si sus volúmenes de datos son tan grandes que una copia de seguridad completa no tiene tiempo para completarse antes de que comience a ejecutarse la siguiente copia de seguridad. Es posible que también necesite una estrategia de copia de seguridad más granular si los datos de su organización cambian con tanta frecuencia que las actualizaciones son de misión crítica para su organización. Para hacer que su estrategia de copia de seguridad sea más granular: - **Amplíe el ámbito de sus copias de seguridad a objetos específicos**. Esta estrategia implica realizar copias de seguridad de registros desde diferentes objetos en diferentes intervalos de tiempo. Tenga en cuenta que los objetos secundarios deben realizarse copias de seguridad en los mismos intervalos que sus principales para mantener la coherencia de los datos. - **Copias de** seguridad **parciales de Timebox**. Esta estrategia implica diferenciar entre copias de seguridad completas (de todos los datos y metadatos) y copias de seguridad parciales (de solo metadatos y registros que se agregaron o cambiaron desde la última copia de seguridad). **\*No deje nunca de realizar copias de seguridad completas**. Es importante tener en cuenta que nunca debe eliminar las copias de seguridad completas por completo, incluso si los volúmenes de datos dan como resultado tiempos de ejecución largos. Para grandes volúmenes de datos, planifique copias de seguridad completas regulares pero poco frecuentes (por ejemplo, copias de seguridad semanales). Planifique también copias de seguridad parciales o específicas de objetos más frecuentes (por ejemplo, copias de seguridad nocturnas o copias de seguridad cada X horas). Este enfoque le proporciona la flexibilidad de reconstruir el conjunto de datos más completo y preciso para utilizar en sus procesos de restauración.\* Los [patrones y antipatrones para planificación de continuidad](/docs/architect/es-mx/well-architected/guide/resilient#patrones-y-antipatrones-de-planificación-de-la-continuidad) muestran el aspecto adecuado y deficiente de las funciones de copia de seguridad y restauración en una solución de Salesforce. Utilícelos para validar sus diseños antes de construir, o para identificar lugares en su sistema que necesitan refactorizarse. ### Copia de seguridad y recuperación de Salesforce Copia de seguridad y recuperación de Salesforce, una solución integrada de Salesforce que incluye Recuperación propia desde la adquisición Propia, protege datos importantes de pérdidas o daños. Nuestra solución altamente segura, fácil de configurar y siempre disponible garantiza la continuidad del negocio y la resiliencia de los datos, y simplifica el cumplimiento. Utilice Copia de seguridad y recuperación de Salesforce para evitar la pérdida de datos, recuperarse de incidentes de datos rápidamente y simplificar su estrategia general de gestión de datos. Puede crear políticas de copia de seguridad para datos de alto valor y regulados, y restaurar esos datos con solo unos clics. #### Implementar copias de seguridad automatizadas Las copias de seguridad diarias automatizadas protegen todos los datos cruciales de su organización, incluyendo metadatos, entornos sandbox, datos de paquetes gestionados, archivos adjuntos y mucho más. Ejecute copias de seguridad con la frecuencia necesaria para cumplir sus objetivos de objetivo de punto de recuperación (RPO) y salvaguardar sus implementaciones. Las copias de seguridad son siempre accesibles y se almacenan de forma segura y conforme. Protección de datos continua también está disponible para datos aún más confidenciales o transaccionales, lo que permite una recuperación más rápida de información crítica que cambia rápidamente. #### Monitorear datos de forma proactiva Detecte actividad de datos inusual, pérdida de datos y corrupción con alertas proactivas que se envían directamente a su email. Reciba alertas en tiempo real para identificar anomalías estadísticas o para crear reglas que le notifiquen de actividad de datos inusual, ayudándole a detectar incidentes más rápido que nunca. #### Restaurar con precisión y rapidez Copia de seguridad y recuperación de Salesforce acelera la recuperación proporcionando visibilidad granular de los cambios, permitiendo la identificación y restauración rápidas de los datos afectados. Herramientas como gráficos visuales resaltan cambios no deseados, mientras que las funciones de recuperación fáciles de utilizar restauran con precisión objetos, campos y registros afectados. #### Ampliar el uso de sus copias de seguridad Nuestras herramientas le permiten utilizar copias de seguridad para análisis, auditorías y cumplimiento, ofreciendo datos históricos con capacidad de búsqueda, funciones de búsqueda abiertas para la visibilidad de datos pasados y funciones de exportación para análisis externos o almacenamiento. Esto reutiliza las copias de seguridad sin necesitar API de Salesforce adicionales. #### Gestión de datos de copia de seguridad unificada Copia de seguridad y recuperación ofrece una única consola para consolidar todas las copias de seguridad, la gestión, las operaciones y el cumplimiento. Esta consola le permite acceder, gestionar, personalizar y monitorear copias de seguridad para todas sus organizaciones de producción y entornos sandbox. Con él, también puede ejecutar solicitudes de titulares de datos para garantizar el cumplimiento de los datos de copia de seguridad y tener el control completo para personalizar las programaciones de copia de seguridad, la frecuencia y las políticas de retención. #### Casos de uso clave para la copia de seguridad y recuperación de Salesforce - **Mitigue la repercusión de incidentes de datos**. Copia de seguridad y recuperación de Salesforce ayuda a mitigar incidentes de datos, como ciberataques o actividad interna o externa maliciosa, permitiendo a los usuarios revertir registros afectados a su estado previo al incidente. La función de exportación de Copia de seguridad y recuperación garantiza el acceso continuo y la capacidad de uso de los datos críticos de los usuarios. - **Evitar pérdida permanente** de datos. Los errores humanos siguen siendo la causa principal de pérdida de datos. Backup and& Recover ofrece una solución precisa y rápida a estos errores. - **Cumple con mayor facilidad los requisitos legales** y de cumplimiento de datos. Copia de seguridad y recuperación de Salesforce admite el modelo de responsabilidad compartida, lo que permite la función de autoservicio para las olvidaciones masivas o la rectificación de datos en sus datos de copia de seguridad. Para obtener más información acerca de las herramientas de Salesforce de copia de seguridad y restauración, consulte [Herramientas de Salesforce para Resiliencia](/docs/architect/es-mx/well-architected/guide/resilient#herramientas-de-salesforce-para-la-resiliencia). ### Patrones y antipatrones de planificación de la continuidad Esta tabla muestra una selección de patrones para buscar o crear en su organización, y antipatrones para evitar o dirigir para su corrección. ✨ Descubra más patrones para la planificación de continuidad en el [Explorador de patrones](/docs/architect/es-mx/well-architected-tools/guide/adaptable-continuity-planning) y antipatrones.

	Patrones	Antipatrones
Continuidad de negocio	En su negocio: - Se adopta una mentalidad de “recuperación primero” con un enfoque en poner las funciones y capacidades de negocio de mayor prioridad fuera de impacto lo antes posible. - Existe una programación de mantenimiento para la revisión de planes de prueba de BCP.	En su negocio: - Una mentalidad de "solucionar el problema" es el único enfoque para la gestión de incidentes. - Los planes de prueba de BCP no se actualizan a intervalos regulares.
	En su documentación: - Existe un BCP que contiene pasos para continuar procesando o triajeando datos si Salesforce deja de estar disponible, una lista de eventos que desencadenan el uso del BCP y pasos e intervalos para pruebas de BCP. - El BCP incluye dependencias y sistemas ascendentes y descendentes.	En su documentación: - Un BCP no existe, no está completo o solo incluye Salesforce.
	En sus planes de prueba: - Se tienen en cuenta las áreas de su BCP relacionadas con procesos y personas.	En sus planes de prueba: - Las áreas de su BCP relacionadas con procesos y personas no se tienen en cuenta.
Continuidad tecnológica	En su negocio: - Ha evaluado si necesita construir sistemas de redundancia o conmutación por error intencionados - Las tácticas de recuperación de incidentes están automatizadas siempre que sea posible.	En su negocio: - No ha evaluado la necesidad de redundancia intencionada o sistemas de conmutación por error - Las tácticas de recuperación de incidentes son todas manuales.
Continuidad tecnológica	En su documentación: - El BCP tiene en cuenta recursos adicionales o procedimientos de ruptura de vidrio que los equipos podrían necesitar para responder a incidentes de forma efectiva.	En su documentación: - El BCP no incluye necesidades de asistencia operativa.
Copia de seguridad y restauración	En su documentación: - Existe una estrategia de copia de seguridad y restauración para datos y metadatos.	En su documentación: - Una estrategia de copia de seguridad y restauración no existe, o si lo hace, está incompleta, aplicándose solo a datos o solo metadatos, no a ambos.
Copia de seguridad y restauración	En su compañía: - Las copias de seguridad se almacenan en una ubicación segura a la que solo los usuarios autorizados pueden acceder. - Los planes de prueba y los registros de prueba muestran que las restauraciones de datos se prueban en un entorno sandbox de copia completa o parcial al menos dos veces al año.	En su compañía: Las copias de seguridad no son legibles. - Las copias de seguridad se almacenan en ubicaciones a las que los usuarios de negocio no autorizados pueden acceder. - No hay ningún proceso de restauración de datos o el proceso de restauración de datos no está probado.

## Herramientas de Salesforce para la resiliencia

Herramienta	Descripción	Gestión del ciclo de vida de aplicaciones	Respuesta de incidente	Planificación de continuidad
Pruebas de Apex Hammer	Obtenga información acerca de las pruebas de Salesforce Apex en versiones actuales y nuevas.	X
API de código auxiliar Apex	Cree un marco de trabajo simulado para simplificar las pruebas.	X
Copia de seguridad y recuperación	Genere copias de seguridad automáticamente para evitar la pérdida de datos.			X
Big Objects	Almacene y gestione grandes volúmenes de datos en la plataforma.			X
Seguimiento del historial de campos	Realice un seguimiento y muestre el historial de campos.		X
Obtener perspectivas de adopción y seguridad para su organizaciónAbrir vínculo en una nueva ventana	Monitoree la adopción y el uso de Lightning Experience en su organización.		X
Gestionar trabajos de carga de datos masiva	Cree actualizaciones o elimine grandes volúmenes de registros con la API masiva.		X
Gestionar eventos de monitoreo de eventos en tiempo real	Gestione la configuración de almacenamiento y transmisión de monitoreo de eventos.		X
Recursos de datos y almacenamiento	Vea los límites de almacenamiento y el uso de su organización de Salesforce.		X
Monitorizar registros de depuración	Monitoree los registros y establezca indicadores para desencadenar el registro.		X
Monitorear la actividad de inicio de sesión con análisis forense de inicio de sesión	Identifique el comportamiento que puede indicar fraude de identidad.		X
Monitorear cambios de configuración con Configuración Seguimiento de auditoría	Realice un seguimiento de los cambios de configuración recientes realizados por los administradores.		X
Monitorizar historial de entrenamiento	Vea las clases de capacitación de Salesforce que tomaron sus usuarios.		X
Monitoreo de trabajos en segundo plano	Monitoree trabajos en segundo plano en su organización.		X
Monitoreo de trabajos programados	Vea instantáneas de reportes, trabajos Apex programados y actualizaciones de tableros.		X
Prueba de escala	Pruebe el desempeño del sistema e interprete los resultados.	X
Proactive Monitoring	Minimice las interrupciones utilizando servicios de monitoreo de Salesforce.		X
Salesforce Data Mask	Enmascare automáticamente datos en un entorno sandbox.	X
La página Descripción general del sistema	Vea datos de uso y límites para su organización.		X
Utilizar force:lightning:lint	Analice y valide código a través de Salesforce CLI.	X

## Recursos relevantes para resilientes

Recurso	Descripción	Gestión del ciclo de vida de aplicaciones	Respuesta de incidente	Planificación de continuidad
7 Antipatrones en pruebas de desempeño y escala	Evite antipatrones comunes en pruebas de desempeño y escala.	X
Analizar el desempeño y ampliar puntos de acceso en aplicaciones complejas de Salesforce	Aprenda un enfoque para solucionar problemas de desempeño y capacidad de ampliación en su organización.	X
Crear un plan de recuperación de desastres (Trailhead)	Cree un plan de recuperación de desastres.			X
Continuidad de negocio es más que copia de seguridad y restauración	Obtenga una vista integral de BCP.			X
Plantilla de estándares de diseño	Cree estándares de diseño para su organización.	X
Herramientas de diagnóstico y monitoreo en Salesforce	Aprenda cómo mejorar la calidad y el desempeño de sus implementaciones.		X
Principios rectores para la planificación de la continuidad del negocio	Revise los principios básicos subyacentes al BCP efectivo.			X
Cómo realizar una Prueba de escala en Salesforce	Conozca las cinco fases del ciclo de vida de las pruebas de escala.	X
Introducción a las pruebas de desempeño	Aprenda cómo desarrollar un método de prueba de desempeño.	X
Monitorear su organización	Obtenga información acerca de opciones de monitoreo de autoservicio.		X
Plantilla de estrategia de prueba	Cree y personalice planes de prueba de escala y desempeño.	X
Plantilla de estrategia de prueba	Asegúrese de que su estrategia de prueba está completa.	X
Comprender el desarrollo dirigido por origen (Trailhead)	Obtenga información acerca del desarrollo de paquetes y organizaciones borrador.	X

## Dinos lo que piensas Ayúdenos a mantener Salesforce Well-Architected relevante para usted; realice nuestra [encuesta](https://sfdc.co/bxNtvh) para proporcionar comentarios sobre este contenido e indicarnos qué le gustaría ver a continuación. > Lea sobre nuestras programaciones de actualizaciones [aquí](/docs/architect/es-mx/well-architected/guide/contributors). ## Introducción Un sistema seguro protege los datos y las partes interesadas de una organización. Las arquitecturas seguras verifican las identidades de los usuarios, restringen el acceso a los datos solo a la información necesaria y evitan que los datos se vean comprometidos. Salesforce da prioridad a Customer Trust y seguridad de datos. Salesforce Platform garantiza la privacidad y la seguridad. La información de seguridad y desempeño del sistema en tiempo real está disponible en [Salesforce Trust](https://trust.salesforce.com/). La protección de sus datos de organización y cliente es la base de la creación de soluciones seguras de Salesforce. Como arquitecto de Salesforce, es responsable de proteger sus datos de organización y cliente utilizando las funciones de seguridad integradas de Salesforce. Tenga en cuenta la distribución geográfica, la industria, los procedimientos operativos de la compañía y los tipos de datos de clientes al tomar estas decisiones. Puede hacer que sus soluciones sean más seguras centrándose en tres áreas: seguridad organizativa, seguridad de sesión y seguridad de datos. ## Seguridad organizativa La seguridad organizativa protege los sistemas del acceso no autorizado garantizando que solo los usuarios autorizados validados puedan acceder a un sistema y solo las funciones y los datos necesarios. Las señales de que tiene seguridad organizativa problemática incluyen: - Procesos ad hoc para activar o desactivar usuarios - Pasos poco claros para actualizar la autorización para cambios de funciones de usuario o sistema - Confianza en el Knowledge institucional de las personas para las asignaciones de seguridad de usuario correctas - Fallo en la alineación con marcos de trabajo de seguridad establecidos o mejores prácticas de la industria - Ausencia de un marco de trabajo de gobernanza de datos estructurado y políticas de apoyo Puede crear mejores controles de seguridad organizativa para sus organizaciones de Salesforce centrándose en la autenticación y la autorización. ### Autenticación La autenticación es crucial para la seguridad y la gestión del acceso, verificando la identidad de los usuarios que intentan acceder a su sistema. Esto se aplica a usuarios humanos (empleados, clientes) y usuarios automatizados (sistemas externos, integraciones), con cada tipo de usuario requiriendo esquemas de autenticación específicos. Para garantizar un acceso seguro entre todos los puntos de entrada de Salesforce en su organización, deberá configurar varios métodos de autenticación. Para crear flujos de autenticación seguros en Salesforce: - **Cree usuarios de Salesforce basándose en individuos, no personas**. Las funciones de auditoría integradas de Salesforce son más efectivas cuando cada cuenta de usuario corresponde a un único individuo que accede a la plataforma. El uso de cuentas de usuario compartidas compromete la efectividad de estas auditorías, introduce vulnerabilidades de seguridad adicionales, aumenta el posible impacto de las brechas de cuentas y complica su capacidad para crear esquemas de autorización efectivos. Esto incluye cuentas de usuario para usuarios de integración. - **Escenarios de acceso** seguros basados en la interfaz de usuario. La mayoría de los usuarios humanos requieren algún tipo de acceso basado en la interfaz de usuario (a menudo denominado acceso de inicio de sesión) para una organización de Salesforce. Salesforce proporciona varias capas de protección para estos escenarios de inicio de sesión, incluyendo: - **Políticas de contraseña.** Los ciberdelincuentes a menudo seleccionan nombres de usuario y contraseñas para obtener acceso no autorizado a aplicaciones. Aunque la configuración de [políticas de contraseña](https://help.salesforce.com/s/articleView?id=sf.admin_password.htm&type=5) es un paso fundamental en la protección del acceso de inicio de sesión, es importante tener en cuenta que esto por sí solo no es suficiente, ya que Salesforce permite sustituciones por usuario de estas políticas. - **Autenticación de múltiples factores (MFA)**. Salesforce [requiere MFA](https://help.salesforce.com/s/articleView?id=000352937&type=1) para todos los inicios de sesión de usuarios basados en la interfaz de usuario. MFA proporciona una defensa esencial contra fugas de credenciales y ataques de fuerza bruta requiriendo a los usuarios proporcionar una forma adicional de identificación, o factor, después de ingresar correctamente su nombre de usuario y contraseña. Este factor adicional suele adoptar una forma física, como un dispositivo móvil, una llave de seguridad o un marcador biométrico. - **Inicio de sesión único (SSO)**. En escenarios de SSO, los usuarios solo utilizan un conjunto de credenciales en las aplicaciones de una organización. El acceso a los sistemas se aprovisiona y gestiona desde una ubicación central, lo que mejora la seguridad. Salesforce puede actuar como proveedor de servicio o proveedor de identidad en [escenarios de SSO](https://help.salesforce.com/s/articleView?id=sf.sso_about.htm&type=5). Asegúrese de permitir que algunos o todos los administradores inicien sesión directamente en Salesforce de modo que puedan solucionar cortes o problemas con su implementación de SSO. - **Pasos posteriores al inicio de sesión.** Para algunos casos de uso, es posible que necesite que los usuarios completen pasos adicionales antes de acceder a su sistema. Se pueden implementar flujos de inicio de sesión personalizados para guiar a los usuarios por estos pasos de proceso adicionales. Algunos ejemplos incluyen: - Aceptación de condiciones - Trabajar en [escenarios de descubrimiento de inicios de sesión y de inicio de sesión sin contraseña](https://help.salesforce.com/s/articleView?id=sf.external_identity_passwordless_login_use_cases.htm&type=5) - Limitación del número de sesiones de Salesforce simultáneas por usuario para reducir la probabilidad de ataques basados en sesiones (consulte [Seguridad de sesión](/docs/architect/es-mx/well-architected/guide/secure#seguridad-de-sesión)). - Conexión a servicios de geovalla - **Escenarios de acceso** seguros basados en API. Cualquier usuario puede solicitar acceso basado en API para una organización de Salesforce. Salesforce proporciona varias capas de protección para escenarios basados en API, incluyendo: - **Control de acceso** de API. Sin [control de acceso](https://help.salesforce.com/s/articleView?id=sf.security_api_access_control_about.htm&type=5) de API, cualquier usuario con un conjunto válido de credenciales puede aprovechar cualquier aplicación para conectar con su organización, incluso si la aplicación conectada no está implementada en la organización. Los controles de acceso a datos aún se aplicarán, pero los usuarios podrían acceder a la información de formas no controladas. Por ejemplo, una aplicación podría utilizarse para descargar grandes volúmenes de datos, o incluso cargar información dañada, sin la aprobación de un administrador del sistema. - **Permisos Solo API**. Puede configurar permisos de usuario Solo API en Salesforce. Asigne esto como parte de un conjunto de permisos a cualquier persona automatizada o [usuario de integración](https://help.salesforce.com/s/articleView?language=en_US&id=sf.integration_user.htm) para bloquear el acceso basado en la interfaz de usuario completamente. - **Certificados y claves**. Los [certificados y claves](https://help.salesforce.com/s/articleView?id=sf.security_keys_about.htm&type=5) permiten a Salesforce validar las solicitudes procedentes de negocios o compañías autorizados. Tendrá que configurar certificados y claves si desea utilizar [SSO con Salesforce](https://help.salesforce.com/s/articleView?id=sf.sso_about.htm&type=5). - **Aplicaciones conectadas**. La configuración de [aplicaciones conectadas](https://help.salesforce.com/s/articleView?id=sf.connected_app_overview.htm&type=5) en Salesforce le permite controlar el acceso del sistema externo a Salesforce, incluyendo protocolos de autenticación obligatorios, ámbito de autorización y comportamiento de sesión en una sola definición. - **Credenciales nombradas**. Las [credenciales nombradas](https://help.salesforce.com/s/articleView?id=sf.named_credentials_define.htm&type=5) le permiten controlar puntos de acceso externos y protocolos de autenticación en una sola definición dentro de Salesforce. Utilícelos para definir y gestionar de forma segura la autenticación para llamadas desde Apex, servicios externos y orígenes de datos Salesforce Connect. - **Agentforce Agent Users Authentication**. Los agentes Agentforce, creados sobre Salesforce, utilizan objetos agente-usuario con permisos gestionables como los de usuarios reales. Al configurar un agente, alinee cuidadosamente el acceso con la función que desempeña el agente, limitando el acceso a los datos solo a lo que se requiere para servir a los usuarios finales. Igual de importante, los agentes se pueden configurar con acciones públicas y privadas. Para acciones privadas, valide y autentique usuarios finales, asignándolos a contexto de agente. Esto permite al agente imitar y operar dentro de los controles de acceso del usuario final, manteniendo la seguridad y Trust. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/secure#patrones-y-antipatrones-de-seguridad-organizativa) a continuación muestra el aspecto de la arquitectura de autenticación adecuada (y deficiente) en una organización de Salesforce. Utilice estos para validar sus diseños antes de construir o identificar oportunidades para mejoras adicionales. Para obtener más información acerca de las herramientas de autenticación disponibles en Salesforce, consulte [Herramientas relevantes para proteger](/docs/architect/es-mx/well-architected/guide/secure#herramientas-relevantes-para-proteger). ### Autorización La autorización define a qué funciones, funcionalidades y datos puede acceder un usuario, así como las acciones que puede realizar con esos recursos, después de que se hayan [autenticado](/docs/architect/es-mx/well-architected/guide/secure#autenticación). Los controles de autorización no son solo para usuarios humanos, también deben adaptarse para usuarios Agentforce Agent, especialmente Agentes que proporcionan servicios a usuarios finales no autenticados. Aunque restringir quién puede autenticarse en su organización es un primer paso crucial, es igualmente vital emparejar una autenticación sólida con una autorización sólida. Sin controles de autorización adecuados, los usuarios podrían crear, modificar y eliminar registros o acceder a funciones del sistema de formas perjudiciales para su negocio y sus partes interesadas. Un control de autorización inadecuado también puede hacer que los sistemas sean más difíciles de utilizar. Al controlar lo que los usuarios pueden hacer dentro del sistema, fomenta niveles más altos de Trust, salvaguardando tanto su sistema como sus usuarios. Para crear esquemas de autorización seguros para Salesforce: - **Siga el principio del menor privilegio**. Abrace el principio de menor privilegio (PoLP) asignando a los usuarios solo los permisos necesarios para sus tareas. Para seguir este principio, diseñe conjuntos de permisos granulares y modulares. Esto permite controles de acceso sofisticados a través de grupos de conjuntos de permisos, permitiendo una gestión precisa de los permisos, incluyendo la capacidad de [silenciar](https://help.salesforce.com/s/articleView?id=sf.perm_set_groups_muting.htm&type=5), [establecer fechas de caducidad](https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_permissions_assn_expiration.htm&type=5&release=238) y mucho más. Alinee sus [unidades funcionales](/docs/architect/es-mx/well-architected/guide/composable#unidades-funcionales) de sistemas con funciones de negocio para definir permisos granulares y grupos de conjuntos de permisos efectivos. Recuerde que los permisos se aplican al acceso _a metadatos_ en Salesforce. Para obtener detalles acerca de la configuración de PoLP para el acceso _a datos de_ Salesforce, consulte [Compartir y visibilidad](/docs/architect/es-mx/well-architected/guide/secure#colaboración-y-visibilidad). - **Piense en el acceso de usuarios en términos de personas, no individuos**. Pensar en la autorización (o la seguridad en general) en términos de usuarios individuales no configurará su sistema para escalarse y evolucionar. En su lugar, diseñe y gestione personas que representan grupos de usuarios. Las soluciones seguras de Salesforce utilizan individuos para la autenticación y personas para la autorización. Al definir configuraciones de seguridad para distintas personas, obtiene un control granular sobre el acceso y los privilegios en su modelo de seguridad, lo que minimiza la necesidad de refactorización a largo plazo. Incluya las personas de seguridad que defina en sus [estándares y documentación](/docs/architect/es-mx/well-architected/guide/intentional#legibilidad) de diseño. - **Controle el acceso de usuarios a metadatos utilizando conjuntos de permisos y grupos de conjuntos de permisos**. Los conjuntos de permisos y los grupos de conjuntos de permisos rigen a qué metadatos pueden acceder los usuarios y qué pueden hacer con esos metadatos. Para obtener más información acerca de los metadatos de Salesforce, consulte [Metadatos frente a datos](/docs/architect/es-mx/fundamentals/guide/architecture-basics#metadatos-frente-a-datos). Configure asignaciones de aplicaciones, activaciones de licencias de funciones, acceso a paquetes gestionados, permisos del sistema, acceso [a CRUD](https://developer.salesforce.com/docs/atlas.en-us.214.0.lightning.meta/lightning/apex_crud_fls.htm) y acceso a nivel de campo a través de conjuntos de permisos y grupos de conjuntos de permisos. Incluya este acceso en sus [estándares y documentación](/docs/architect/es-mx/well-architected/guide/intentional#legibilidad) de diseño. - **Utilice valores predeterminados de toda la organización (OWD) y colaboración para controlar el acceso a los datos de los usuarios**. Los [datos y metadatos](/docs/architect/es-mx/fundamentals/guide/architecture-basics#metadatos-frente-a-datos) son entidades distintas en Salesforce, que requieren controles de acceso separados para cada una. Utilice OWD y herramientas de colaboración integradas para configurar el acceso para datos de Salesforce (registros individuales, archivos y documentos). Para obtener más detalles, consulte [Seguridad de datos](/docs/architect/es-mx/well-architected/guide/secure#seguridad-de-datos). - **Utilice ámbitos de OAuth para controlar el acceso para aplicaciones conectadas**. Al configurar una aplicación conectada, define el [ámbito](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US) o los permisos de acceso que tendrán los usuarios de la aplicación a recursos de Salesforce. Para obtener más información acerca de la gestión de tokens de OAuth, consulte [Gestión de sesiones](/docs/architect/es-mx/well-architected/guide/secure#gestión-de-sesiones). - **Cree un usuario de Salesforce para cada integración**. Para adherirse al principio de menor privilegio, cree un [usuario de integración](https://help.salesforce.com/s/articleView?id=sf.integration_user.htm) de Salesforce exclusivo para cada integración. Esto le permite asignar acceso a datos específicos, mejorando el control sobre las operaciones, garantizando la trazabilidad de las transacciones y minimizando el impacto de posibles brechas de seguridad. - **Implemente cuentas exclusivas con el PoLP para todos los usuarios Agente**. Cada Usuario de Agentforce Agent debe ser exclusivo y no reutilizarse entre múltiples Agentes. Los permisos para estas cuentas deben respetar estrictamente el principio de menor privilegio. Tenga en cuenta que las acciones ejecutadas por un usuario agente pueden operar en un contexto de seguridad elevado dentro de Salesforce o contra sistemas externos que no respetan los controles de acceso de Salesforce. Esto podría llevar a Acciones a acceder o revelar información confidencial a usuarios. - **Reduzca al mínimo el uso de perfiles y migre cualquier control de acceso de perfiles**. Los perfiles permiten limitar el acceso a [intervalos de direcciones](https://help.salesforce.com/s/articleView?id=sf.security_networkaccess.htm&type=5) IP, [horas de inicio](https://help.salesforce.com/s/articleView?id=sf.login_hours.htm&type=5) de sesión y funciones específicas de la interfaz de usuario heredada de Salesforce Classic (específicamente tipos de registro predeterminados y asignaciones de formatos de página). Cualquier otra función actualmente en perfiles debe migrarse a funciones equivalentes en [conjuntos de permisos](https://help.salesforce.com/s/articleView?id=sf.perm_set_groups_create_with_perm_sets.htm) y grupos de conjuntos de permisos. Las funciones en sus perfiles vinculadas a funciones de la interfaz de usuario Salesforce Classic deben dirigirse para su corrección. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/secure#patrones-y-antipatrones-de-seguridad-organizativa) a continuación muestra el aspecto de las prácticas de autorización adecuadas (y deficientes) en una organización de Salesforce. Utilice estos para validar sus diseños antes de construir o identificar oportunidades para mejoras adicionales. Para obtener más información acerca de las herramientas de autorización disponibles en Salesforce, consulte [Herramientas relevantes para proteger](/docs/architect/es-mx/well-architected/guide/secure#herramientas-relevantes-para-proteger). ### Patrones y antipatrones de seguridad organizativa Esta tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su corrección. ✨ Descubra más patrones para la seguridad organizativa en el [Explorador de patrones](/docs/architect/es-mx/well-architected-tools/guide/trusted-organizational-security) y antipatrones.

	Patrones	Antipatrones
Autenticación	En sus estándares de diseño y documentación: - Las personas de seguridad aprobadas están claramente definidas y enumeradas - La asignación entre personas de seguridad y esquemas de autenticación permitidos (UI, API) existen en una matriz de seguridad	Si existen estándares de diseño y documentación, estos: - No incluir personas de seguridad - No incluir una matriz de seguridad con asignaciones claras para personas de seguridad y esquemas de autenticación permitidos
	En su organización: - Las configuraciones de inicio de sesión se alinean con la Comprobación de Salesforce MFA - La relación entre usuarios y entidades que inician sesión en Salesforce es 1:1 (sin usuarios compartidos) - Control de acceso de API evita que los usuarios se autentiquen a través de una aplicación conectada no autorizada - Si SSO está activado, los usuarios administradores aprobados tienen acceso de inicio de sesión directo	En su organización: - Las configuraciones de inicio de sesión no se alinean con la Comprobación de Salesforce MFA - La relación entre usuarios y entidades que inician sesión en Salesforce no es 1:1 (hay cuentas de usuario compartidas) - Si los usuarios acceden a Salesforce desde detrás de un cortafuegos, el cortafuegos utiliza direcciones IP codificadas para proteger las comunicaciones a/desde Salesforce - Control de acceso de API no está activado - Si SSO está activado, ningún usuario administrador aprobado tiene acceso de inicio de sesión directo
	In LWC, Apex, Aura: - Los métodos que ejecutan la autenticación utilizan credenciales nombradas para gestionar flujos de nombre de usuario/contraseña - No aparecen nombres de usuario o contraseñas en código en formatos legibles (sin valores codificados o cadenas) - Si existen flujos de inicio de sesión personalizados, todo el código personalizado relacionado utiliza métodos `de SessionManagement` apropiados	In LWC, Apex, Aura: - La autenticación se gestiona ad hoc - Los nombres de usuario y contraseñas aparecen en código
Autorización	En sus estándares de diseño y documentación: - Cada usuario y sistema con acceso a Salesforce asigna a una o más personas en una matriz de seguridad - La matriz de seguridad enumera claramente permisos de metadatos y personas de usuario asignadas - Los casos de uso para otorgar privilegios elevados se enumeran claramente, incluyendo: -- Modificar todos los permisos de datos -- Ver todos los permisos de datos	Si existen estándares de diseño y documentación, estos: - No incluir una matriz de seguridad - No enumerar claramente permisos - No enumerar claramente casos de uso para otorgar privilegios elevados
	En su organización: - Los conjuntos de permisos y los grupos de conjuntos de permisos se utilizan para controlar el acceso a metadatos - Los conjuntos de permisos y los grupos de conjuntos de permisos se alinean con funciones de negocio - Los permisos asignados a usuarios siguen definiciones de matriz de seguridad - Los perfiles se utilizan mínimamente y solo para controlar intervalos de direcciones IP de inicio de sesión y horas de inicio de sesión - Un usuario de integración solo de API exclusivo está configurado para cada integración	En su organización: - Los grupos de conjuntos de permisos no están configurados para permitir el acceso basándose en funciones de negocio - Los conjuntos de permisos están configurados ad hoc - Los conjuntos de permisos son redundantes o están muy duplicados; es difícil comprender una lógica funcional clara y diferencias entre conjuntos - Los permisos asignados a usuarios no siguen definiciones de matriz de seguridad - Los perfiles contienen controles de acceso para metadatos - Los usuarios solo de API no están configurados o están compartidos entre más de una integración
	En Apex: - Las operaciones de base de datos realizan comprobaciones de acceso a nivel de campo y objeto de forma apropiada, incluyendo: -- Las declaraciones DML y DML de base de datos declaran el modo usuario o sistema para operaciones de datos Y/O -- Las declaraciones DML y DML de base de datos utilizan métodos `stripInaccessible` antes de operaciones de datos -- Las declaraciones SOQL y SOSL utilizan las palabras clave `WITH USER_MODE` y `WITH SYSTEM_MODE` AND/OR -- Los métodos `stripInaccessible` se utilizan para filtrar resultados de consultas y subconsultas -- Los métodos de resultados de descripción de sObject (es decir, `isAccessible`, `isCreateable`, `isUpdateable` y/o `isDeletable`) se utilizan con moderación	En Apex: - DML, métodos de Clase de base de datos, SOQL y SOSL se ejecutan en modo de sistema predeterminado - Las operaciones de la base de datos no realizan comprobaciones de acceso de forma apropiada, incluyendo: -- Los métodos DML o Clase de base de datos utilizan exclusivamente comprobaciones `isAccessible`, `isCreateable`, `isUpdateable` y/o `isDeletable` para el acceso a nivel de campo y sObject -- Las consultas SOQL utilizan exclusivamente palabras clave `WITH SECURITY_ENFORCED` para restricciones de acceso
	En flujos (Consideraciones de seguridad para diseño de flujos): - Los flujos utilizan el Contexto de ejecución más restrictivo posible, idealmente Modo de usuario - El acceso a datos confidenciales o privilegiados de seguridad se realiza por Subflujos para minimizar el contexto de ejecución - Limitar la lógica realizada en flujos desencadenados por registros - Las entradas de flujo se validan para garantizar que solo se pasan las cargas permitidas como entrada	En Flujos: - Los flujos se ejecutan en Modo sistema o Modo sistema sin colaboración, independientemente de las acciones que realice el flujo - Toda la lógica de flujo se realiza dentro de un único flujo grande - Las entradas de flujo no se validan y se pasan a consumidores sin verificación

## Seguridad de sesión Una sesión es la serie de solicitudes y respuestas asociadas con un usuario durante un periodo de tiempo. Una sesión se inicia cuando un usuario se autentica correctamente en Salesforce. La [seguridad de sesión](https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.security_overview_sessions.htm) es la práctica de configurar su sistema para evitar accesos no autorizados y violaciones de datos frustrando la interferencia o el secuestro de sesiones. Toda la actividad del usuario en su sistema se produce en el contexto de una sesión, de modo que es fundamental tener en cuenta cómo se inician las sesiones, qué puede tener lugar durante una sesión, qué dispositivos emplearán (y deben) los usuarios y cómo detectar y responder a comportamientos de sesión sospechosos o anómalos. Puede crear seguridad de sesión en Salesforce centrándose en tres claves: gestión de sesiones, acceso a dispositivos y detección y respuesta de amenazas. ### Gestión de sesiones Las sesiones se inician cuando un usuario se autentica correctamente y obtiene acceso a Salesforce. Estas sesiones permiten a la plataforma asociar solicitudes y respuestas específicas con ese usuario concreto. El protocolo HTTPS facilita la comunicación entre un cliente front-end y Salesforce Platform. Los clientes pueden incluir navegadores, aplicaciones móviles, aplicaciones locales, etc. HTTPS es un protocolo sin estado, lo que significa que cada comunicación es discreta y no está relacionada con ninguna comunicación anterior o futura. Este enfoque sin estado acelera las comunicaciones de red y elimina errores causados por vínculos dañados entre paquetes. Sin embargo, las aplicaciones web aún necesitan una forma de realizar un seguimiento de la identidad de cada usuario y otra información relacionada entre múltiples interacciones de solicitud y respuesta. Salesforce, al igual que la mayoría de las aplicaciones web, logra esto utilizando sesiones y [tokens](https://help.salesforce.com/s/articleView?id=sf.remoteaccess_oauth_tokens_scopes.htm&type=5). - Las **sesiones** permiten a Salesforce asociar solicitudes y respuestas con usuarios. Después de autenticar un usuario, la plataforma envía un Id. de sesión de vuelta a la aplicación cliente, que incluye este Id. con cualquier solicitud de usuario (como navegar, buscar y enviar datos). - Los **tokens** permiten a los usuarios y las aplicaciones conectadas verificar su identidad una vez y utilizar un token de acceso exclusivo a partir de entonces. Los tokens tienen una vida útil limitada y solo proporcionan acceso a recursos específicos (consulte [Autorización](/docs/architect/es-mx/well-architected/guide/secure#autorización) para obtener más información acerca de la configuración de niveles de acceso). Los tokens permiten el acceso a recursos autorizados sin requerir que los usuarios inicien sesión. Si las sesiones y los tokens no están protegidos correctamente, los malos actores pueden interferir con ellos e imitar usuarios o ejecutar código malicioso en su sistema. Para crear una gestión de sesiones segura para Salesforce: - **Comprenda cómo clasifica Salesforce los tipos de sesión**. Identifique y asigne [tipos de sesiones](https://help.salesforce.com/s/articleView?id=sf.security_session_types.htm&type=5) aprobadas a personas de usuario de seguridad, y regístrelas en su documentación. - **Controle cómo se pueden originar las sesiones y dónde puede ir** el tráfico de sesiones. Una vez que haya identificado los tipos de sesiones que varias personas de usuario pueden iniciar, configure controles para bloquear sesiones que se originan desde contextos o orígenes no aprobados. Salesforce proporciona varias formas de controlar los orígenes y el tráfico de sesiones, incluyendo: - **Protección de sesión integrada**. Salesforce activa automáticamente protecciones de toda la organización para actividades maliciosas basadas en sesiones, incluyendo secuencias de comandos de sitio cruzadas, falsificación de solicitudes de sitio cruzadas, [olfateo de contenido](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#mime_sniffing), [secuestro de clics](https://owasp.org/www-community/attacks/Clickjacking) y mucho más. Estas protecciones nunca deben desactivarse; algunas no pueden desactivarse. - **Dominios e intervalos** de IP. Todas las organizaciones de Salesforce tienen [Mi dominio](https://help.salesforce.com/s/articleView?id=sf.domain_name_overview.htm&type=5) activado de forma predeterminada, lo que crea un subdominio específico de la compañía para el acceso a Salesforce. Puede personalizar o cambiar el nombre asociado con una organización a través de Mi dominio. Además, Salesforce admite [configuraciones de dominio](https://help.salesforce.com/s/articleView?id=sf.domain_mgmt_overview.htm&type=5) adicionales para sitios de Experience Cloud y otras páginas de aplicación. Nota: Si sus usuarios necesitan acceder a Salesforce desde detrás de un cortafuegos de compañía, agregue los [dominios requeridos](https://help.salesforce.com/s/articleView?id=sf.setup_domains.htm&type=5) a sus listas de admisión de cortafuegos. Puede configurar [intervalos de direcciones](https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/users_profiles_epui_login_ip_ranges_edit.htm) IP y [intervalos de direcciones](https://help.salesforce.com/s/articleView?id=sf.security_networkaccess.htm) IP de confianza para controlar las solicitudes de inicio de sesión y de inicio de sesión entrantes en Salesforce. - **Horas de inicio** de sesión. Si algunas personas de usuario establecieron horarios laborales, puede restringir su capacidad de acceder a Salesforce fuera del [horario de inicio](https://help.salesforce.com/s/articleView?id=sf.login_hours.htm&type=5) de sesión definido. - **Controle actividades que requieren seguridad a nivel de sesión** adicional. De forma predeterminada, las sesiones pueden tener dos tipos de [niveles de seguridad](https://help.salesforce.com/s/articleView?id=sf.security_overview_sessions.htm&type=5): estándar y de alta seguridad. Utilice estos niveles de seguridad para controlar cómo los usuarios pueden y no pueden realizar actividades como acceder a reportes y tableros o gestionar las configuraciones de seguridad en una organización de Salesforce. Las políticas de seguridad a nivel de sesión pueden requerir que los usuarios establezcan [sesiones de alta seguridad](https://help.salesforce.com/s/articleView?id=sf.security_auth_require_ha_session.htm&type=5) para realizar operaciones o bloquear a los usuarios la realización de cualquier operación confidencial. - **Controle las actividades que requieren permisos basados en sesión** agregados. Salesforce admite activaciones de [permisos basadas en sesiones](https://help.salesforce.com/s/articleView?id=sf.perm_sets_session_use.htm&type=5) para permitir temporalmente a los usuarios autorización elevada o acceso a permisos durante una sesión concreta. Puede activar y desactivar permisos basados en sesión a través de las API de Salesforce o Flow. - **Gestione sesiones de usuario inactivas a través de tiempos de espera**. La finalización de sesiones inactivas es una parte clave de la gestión de la seguridad de la sesión. Esto ayuda a proteger su sistema cuando, por ejemplo, un usuario deja una sesión de Salesforce abierta en una ficha del navegador pero está trabajando activamente en otra aplicación, o cuando el dispositivo móvil de un usuario inicia sesión en Salesforce, pero no recibe atención. Salesforce tiene un tiempo de inactividad de sesión predeterminado de dos horas. Puede aumentar o disminuir los niveles de tiempo de espera de inactividad de sesiones, pero el aumento de los tiempos de espera solo debe realizarse con una justificación convincente y bien documentada. - **Gestione sesiones de aplicaciones conectadas a través de la configuración de tokens.** Cuando configura una aplicación conectada, también define el ámbito o el nivel de autorización que se otorgará a los usuarios que accedan a Salesforce a través de la aplicación conectada. Este ámbito se aplica a nivel de sesión a través de [tokens de OAuth](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US), que se emiten después de que un usuario de una aplicación conectada se autentique correctamente. Puede controlar el tiempo que debe durar un token a través de [políticas de actualización](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US) de tokens. Los administradores de organizaciones pueden revocar tokens manualmente por usuario y por organización, si es necesario. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/secure#patrones-y-antipatrones-de-seguridad-de-sesión) a continuación muestra el aspecto de la gestión de sesiones adecuada (y deficiente) en una organización de Salesforce. Utilice estos para validar sus diseños antes de construir o identificar oportunidades para mejoras adicionales. Para obtener más información acerca de las herramientas de gestión de sesiones disponibles en Salesforce, consulte [Herramientas relevantes para proteger](/docs/architect/es-mx/well-architected/guide/secure#herramientas-relevantes-para-proteger). ### Acceso de dispositivo En el contexto actual, un _dispositivo_ es cualquier equipo electrónico que una persona utilizará para acceder a Salesforce, como una estación de trabajo de escritorio, un portátil, una tablet o un teléfono celular. Los dispositivos portátiles ofrecen a los usuarios la flexibilidad de acceder a Salesforce desde cualquier ubicación. Sin embargo, esta comodidad podría introducir vectores de ataque adicionales para actores malintencionados. Estos vectores de amenazas van desde tácticas sencillas, como navegar por los hombros en un lugar público para robar credenciales, a métodos más sofisticados como instalar malware en un dispositivo o crear una red Wi-Fi pública falsa para interceptar transmisiones de datos. Debido a esto, la protección de dispositivos, especialmente dispositivos portátiles, es esencial para la seguridad general del sistema. Para proteger el acceso de dispositivos para Salesforce: - **Utilice las soluciones de aplicación móvil proporcionadas por Salesforce**. Haga que los usuarios en dispositivos móviles que necesitan acceder a Salesforce utilicen las [aplicaciones Salesforce](https://help.salesforce.com/s/articleView?id=sf.mobile_security.htm&type=5) oficiales disponibles para iOS y Android. Si las necesidades de negocio requieren una solución móvil personalizada, debe utilizar el [Salesforce Mobile SDK](https://developer.salesforce.com/docs/atlas.en-us.mobile_sdk.meta/mobile_sdk/intro.htm), que proporciona métodos para la autenticación y autorización seguras. - **Diseñe el uso de dispositivos móviles en su gestión de sesión**. Los niveles de seguridad de sesión, los tiempos de espera de sesión y otros controles de contexto de sesión deben tener en cuenta cualquier acceso anticipado de usuarios en dispositivos móviles. Considere qué dispositivos deben y no deben tener permiso para acceder a Salesforce, y qué tipos de usuarios deben tener acceso a sesiones móviles. Incluya estándares de acceso móvil en la documentación de su persona de seguridad. Para obtener más información sobre este tema, consulte [Gestión de sesiones](/docs/architect/es-mx/well-architected/guide/secure#gestión-de-sesiones). - **Complemente la seguridad a nivel de dispositivo con la tecnología Mobile Device Management (MDM).** Las aplicaciones Salesforce para iOS y Android son [compatibles con muchos conjuntos](https://help.salesforce.com/s/articleView?id=sf.mobile_security_mdm.htm&type=5) de MDM populares. Puede configurar controles de acceso adicionales para la aplicación Salesforce en dispositivos de usuario a través de su solución MDM preferida. - **Complemente la seguridad a nivel de aplicación con la tecnología Gestión de aplicaciones móviles (MAM)**. La tecnología MAM admite controles a nivel de aplicación en dispositivos móviles. Salesforce ofrece un [complemento MAM](https://help.salesforce.com/s/articleView?id=sf.mobile_security_mam_overview.htm&type=5) de pago para aplicaciones móviles Salesforce. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/secure#patrones-y-antipatrones-de-seguridad-de-sesión) a continuación muestra el aspecto adecuado (y deficiente) de la gestión de dispositivos en una organización de Salesforce. Utilice estos para validar sus diseños antes de construir o identificar oportunidades para mejoras adicionales. Para obtener más información acerca de las herramientas de gestión de dispositivos disponibles en Salesforce, consulte [Herramientas relevantes para proteger](/docs/architect/es-mx/well-architected/guide/secure#herramientas-relevantes-para-proteger). ### Detección y respuesta ante amenazas La detección de amenazas es el proceso de identificación de patrones de comportamiento en su sistema que pueden indicar actividad maliciosa. Esto puede incluir volúmenes superiores a la media de datos descargados o un usuario modificando campos que contienen datos confidenciales en varios registros en un periodo de tiempo inferior a la media. Las respuestas a amenazas pueden incluir caducidad de sesión automatizada, alertas y otras notificaciones. El objetivo de la detección de amenazas es identificar y responder a posibles problemas lo más rápido posible. La acción basada en la detección de amenazas en tiempo real puede detener el comportamiento malicioso en sus seguimientos. Salesforce ofrece [monitoreo de eventos](https://help.salesforce.com/s/articleView?id=sf.real_time_event_monitoring_overview.htm&type=5) en tiempo real como complemento o como parte de [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/). Utilice una de estas soluciones si tiene aplicaciones altamente confidenciales o requiere funciones de respuesta y detección de amenazas en tiempo real sólidas. Para crear una estrategia de respuesta y detección de amenazas efectiva para sus soluciones de Salesforce: - **Utilice funciones de auditoría** integradas. Salesforce ofrece una variedad de [herramientas integradas](https://help.salesforce.com/s/articleView?id=sf.monitoring_admin.htm&type=5) para ayudar a realizar un seguimiento y auditar cambios en su organización. Por ejemplo, la [Configuración del seguimiento](https://help.salesforce.com/s/articleView?id=sf.admin_monitorsetup.htm&type=5) de auditoría le permite ver el historial de auditoría de acciones administrativas. Salesforce realiza un seguimiento de los cambios a nivel de campo durante un periodo de tiempo limitado de forma predeterminada, pero puede activar [Seguimiento del historial](https://help.salesforce.com/s/articleView?id=sf.tracking_field_history.htm&type=5) de campos para mostrar los cambios de campo durante un máximo de 18 meses en la interfaz de usuario y hasta 24 meses a través de la API. Además, puede activar [Seguimiento de auditoría](https://help.salesforce.com/s/articleView?id=sf.field_audit_trail.htm&type=5) de campo para mantener un historial de auditoría para cambios a nivel de campo indefinidamente (hasta que elimine manualmente los datos). - **Establezca revisiones periódicas**. La auditoría es crucial para identificar cambios anómalos que la detección de amenazas en tiempo real podría perderse. Considere un escenario donde un usuario con acceso legítimo elimina de forma coherente un pequeño número de registros diariamente durante un periodo prolongado. Puesto que este usuario tiene credenciales de inicio de sesión válidas, autorización apropiada para eliminar registros y no está eliminando un gran volumen de registros a la vez, es poco probable que la actividad se detecte como una amenaza en tiempo real. Sin embargo, un equipo de auditoría que revise los reportes de actividad de los usuarios identificaría claramente esta tendencia de eliminación excesiva de registros por un único usuario a lo largo del tiempo, facilitando su tratamiento. Como parte de sus [políticas de gobernanza](/docs/architect/es-mx/well-architected/guide/intentional#gobernanza), establezca intervalos regulares para auditar el historial de inicio de sesión, la actividad de la sesión de usuario y el uso de la aplicación conectada. - **Desarrolle una estrategia de respuesta ante amenazas e inclúyala en sus políticas de seguridad**. Cree una estrategia de respuesta ante amenazas que cubra: - Definiciones de tipo de respuesta ante amenazas (por ejemplo, alertas y automatizaciones) y cualquier [grupo de](/docs/architect/es-mx/well-architected/guide/resilient#respuesta-de-incidente) partes interesadas. Para obtener más información sobre el diseño de mensajes o alertas, consulte [Errores y notificaciones](/docs/architect/es-mx/well-architected/guide/engaging#notificaciones-y-mensajes). - Categorías específicas para actividades o cambios en tiempo real que podrían considerarse amenazas y el tipo de respuesta asociado para cada una - Una lista clara de todas las respuestas de amenazas automatizadas (como revocar tokens, finalizar sesiones, desactivar cuentas de usuario o bloquear el acceso a recursos) y desencadenadores de automatización Monitoreo de eventos proporciona los datos necesarios para aplicar este principio activando la detección y respuesta de amenazas en tiempo real. Seguridad de transacciones aplica las acciones dirigidas por políticas de su compañía, y los tipos de eventos admiten el monitoreo del acceso de usuarios y aplicaciones a lo largo del tiempo. El servicio nativo de Detección de amenazas de Salesforce utiliza modelos estadísticos y de aprendizaje automático para identificar comportamientos sospechosos. Este servicio genera eventos específicos que protegen contra ataques cibernéticos y acceso a datos sospechosos. Seguridad de transacciones lleva la seguridad un paso más allá ya que proporciona un marco de trabajo que intercepta eventos clave que se producen en su organización y aplica las acciones dirigidas por políticas de su compañía. Esto transforma Monitoreo de eventos de una herramienta de registro en un componente importante de una defensa de seguridad automatizada. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/secure#patrones-y-antipatrones-de-seguridad-de-sesión) a continuación muestra el aspecto adecuado (y deficiente) de la detección y respuesta ante amenazas en una organización de Salesforce. Utilice estos para validar sus diseños antes de construir o identificar oportunidades para mejoras adicionales. Para obtener más información acerca de herramientas de detección de amenazas, alertas y automatización de respuestas disponibles en Salesforce, consulte [Herramientas relevantes para proteger](/docs/architect/es-mx/well-architected/guide/secure#herramientas-relevantes-para-proteger). ### Patrones y antipatrones de seguridad de sesión Esta tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su corrección. ✨ Descubra más patrones para la seguridad de sesiones en el [Explorador de patrones](/docs/architect/es-mx/well-architected-tools/guide/trusted-session-security) y antipatrones.

	Patrones	Antipatrones
Gestión de sesiones	En sus estándares de diseño y documentación: - Las personas de seguridad enumeran claramente los tipos de sesión aprobados y la configuración de tiempo de espera/duración para cada persona - Las horas de inicio de sesión se han especificado (o identificado como no necesarias) - Las operaciones que requieren permisos o seguridad a nivel de sesión elevada son claras y detectables - El ámbito de la aplicación conectada y las políticas de gestión de tokens son claras y detectables	En sus estándares de diseño y documentación: - Las personas de seguridad no existen o carecen de información sobre tipos de sesión y configuración de tiempo de espera/duración - Las políticas de seguridad no contienen información acerca de ámbitos de aplicaciones conectadas o gestión de tokens
	En su organización: - Las auditorías de sesión muestran que los usuarios solo acceden a Salesforce a través de tipos de sesión esperados - Existe un conjunto de permisos claro y activo para el acceso de "Usuario solo de API" (con el permiso "Solo de API" establecido como TRUE) y todos los usuarios de integración y automatizados están asignados - Si los usuarios acceden a Salesforce desde detrás de un cortafuegos, el cortafuegos utiliza una lista de admisión de dominios obligatorios en vez de direcciones IP para proteger las comunicaciones a/desde Salesforce - Los intervalos de tiempo de espera de sesión inactivos no superan el valor predeterminado (2 horas) - Todos los siguientes parámetros están activados: -- Protección contra secuestro de clics para páginas de Configuración -- Protección contra secuestro de clics para páginas de Salesforce que no sean de Configuración -- Protección contra la falsificación de solicitudes de sitio cruzado (CSRF) -- Protección de secuencias de comandos de sitio cruzadas (XSS) -- Activar la protección contra el rastreo de contenido -- Protección de URL de referencia -- Advertir a los usuarios antes de que se les redirija fuera de Salesforce	En su organización: - No hay auditoría de sesión regular - No hay definiciones de qué tipos de sesión deben tener los usuarios - Los permisos "Solo API" no están claros o faltan en la integración y los usuarios automatizados - Si los usuarios acceden a Salesforce desde detrás de un cortafuegos, el cortafuegos utiliza direcciones IP codificadas para proteger las comunicaciones a/desde Salesforce - Los intervalos de tiempo de espera de sesión inactivos superan el valor predeterminado (2 horas) - Cualquiera de los siguientes parámetros está desactivado: -- Protección contra secuestro de clics para páginas de Configuración -- Protección contra secuestro de clics para páginas de Salesforce que no sean de Configuración -- Protección contra la falsificación de solicitudes de sitio cruzado (CSRF) -- Protección de secuencias de comandos de sitio cruzadas (XSS) -- Activar la protección contra el rastreo de contenido -- Protección de URL de referencia -- Advertir a los usuarios antes de que se les redirija fuera de Salesforce
	In LWC, Apex, Aura: - Si existen flujos de inicio de sesión personalizados, todo el código personalizado relacionado utiliza métodos `de SessionManagement` apropiados para asignar seguridad a nivel de sesión	In LWC, Apex, Aura: - Si existen flujos de inicio de sesión personalizados, no hay lógica para asignar seguridad a nivel de sesión
Acceso a dispositivos	En sus estándares de diseño y documentación: - Las políticas de dispositivos son claras y detectables - Las personas de seguridad están claramente asignadas a usos y políticas de dispositivos apropiados	En sus estándares de diseño y documentación: - Las políticas de seguridad no existen o no contienen información sobre el acceso a dispositivos
Acceso a dispositivos	En su organización: - La configuración de la aplicación conectada móvil Salesforce requiere el desbloqueo de PIN/contraseña después de la inactividad - Si las necesidades de negocio requieren un control estricto de los usuarios que pueden acceder a Salesforce Mobile, el Control de acceso de API está activado y los conjuntos de permisos están asignados a todos los usuarios de aplicaciones móviles Salesforce	En su organización: - La aplicación conectada móvil Salesforce no está configurada para requerir desbloqueo de PIN/contraseña por inactividad – Las necesidades de negocio requieren un control estricto de los usuarios que pueden acceder a Salesforce Mobile, pero el Control de acceso de API no está activado o los conjuntos de permisos no se utilizan para controlar el acceso a aplicaciones móviles Salesforce
Detección y respuesta ante amenazas	En sus estándares de diseño y documentación: - Las políticas de seguridad contienen una lista de eventos que deben desencadenar una respuesta junto con el tipo de respuesta apropiado - Se han especificado niveles de auditoría para todos los objetos en su modelo de datos - Los pasos para revisar registros disponibles en Salesforce están documentados - Todas las respuestas automatizadas están documentadas claramente	En sus estándares de diseño y documentación: - Las políticas de seguridad no existen o no incluyen información sobre la detección y alerta de amenazas - La documentación para respuestas automatizadas no existe o no está clara
	Dentro de su compañía: - Los datos de auditoría están disponibles en reportes que las partes interesadas de negocio pueden comprender y acceder - Se realizan revisiones regulares del historial y los reportes de auditoría	Dentro de su compañía: - Los datos de auditoría solo están disponibles a través de archivos de registro que requieren experiencia en la materia para acceder e interpretar - No existen procesos para revisar la información de auditoría
	En su organización: - Existen automatizaciones para responder a amenazas desactivando cuentas de usuario o bloqueando el acceso a recursos en tiempo real si se detecta un uso anormal - Las notificaciones y alertas están configuradas para notificar a los usuarios apropiados sobre actividad anómala - El seguimiento del historial de campos está activado para todos los campos que contienen datos privados o confidenciales	En su organización: - No existen automatizaciones para responder a amenazas - Las notificaciones y alertas no están configuradas para notificar a los usuarios apropiados sobre actividad anómala, o existen algunas notificaciones y alertas relacionadas con actividad anómala, pero son ad hoc - El seguimiento del Historial de campos no está activado de forma coherente para campos que contienen datos privados o confidenciales

## Seguridad de datos La seguridad de los datos es la práctica de proteger sus datos de accesos no autorizados, daños o eliminación no intencionada. La seguridad de los datos implica salvaguardar los datos tanto en tránsito como en periodos de inactividad. Una sólida seguridad de los datos minimiza los riesgos y posibles daños derivados del acceso no autorizado a su sistema. La seguridad de datos inadecuada deja los sistemas vulnerables a las brechas de datos, que pueden afectar gravemente a los clientes y su compañía. Por lo tanto, la protección de sus datos es fundamental para crear arquitecturas seguras. La mejora de la seguridad de los datos comienza con una comprensión clara de lo que se considera datos en Salesforce, junto con su clasificación. Los registros, archivos y documentos individuales almacenados en una organización de Salesforce son sus datos. Para obtener más información sobre la distinción entre metadatos y datos, consulte [Fundamentos de Salesforce Architecture](/docs/architect/es-mx/fundamentals/guide/architecture-basics#metadatos-frente-a-datos). Puede crear una seguridad de datos más sólida en sus soluciones de Salesforce centrándose en la colaboración y la visibilidad, así como el uso de cifrado. > Nota: Al diseñar para la seguridad de los datos, asegúrese de tener en cuenta la [privacidad de datos](/docs/architect/es-mx/well-architected/guide/compliant#privacidad-de-datos), así como el [archivado y purga](/docs/architect/es-mx/well-architected/guide/resilient#planificación-de-continuidad), ya que ambos conceptos afectarán a la seguridad general de los datos de sus soluciones. ### Clasificación de datos Identifique y clasifique todos los datos almacenados en la plataforma Salesforce en base a su confidencialidad (por ejemplo, pública, interna, confidencial, restringida). Defina una **política de clasificación** de datos clara que describa cómo se debe gestionar y proteger cada tipo de datos. Implemente controles de seguridad apropiados, como seguridad a nivel de campo, cifrado y enmascaramiento de datos, para aplicar la política y proteger datos confidenciales de accesos o exposiciones no autorizados. Revise y audite estas clasificaciones y controles regularmente para asegurarse de que permanecen alineados con los requisitos de negocio y cumplimiento. ### Colaboración y visibilidad La colaboración y la visibilidad implican configurar su sistema para controlar cómo acceden los usuarios a los datos en Salesforce. Es importante tener en cuenta que la colaboración y la visibilidad controlan a qué registros individuales puede acceder un usuario, pero estos parámetros por sí solos no controlan en última instancia lo que un usuario puede hacer con un registro concreto, o qué campos específicos en ese registro son visibles. Los permisos para llevar a cabo operaciones de datos (como [CRUD](https://developer.salesforce.com/docs/atlas.en-us.214.0.lightning.meta/lightning/apex_crud_fls.htm)) se asignan a usuarios a través de controles de acceso a metadatos, que se pueden configurar para un usuario a nivel de campo y objeto individual. Para obtener más información al respecto, consulte [Autorización](/docs/architect/es-mx/well-architected/guide/secure#autorización). Las acciones Agentforce pueden exponer datos a usuarios autenticados y anónimos que normalmente carecen de acceso directo. Al crear Agentforce Agents, considere cuidadosamente y documente todas las Acciones asignadas al agente. Para cada acción, debe comprender: - Datos a los que pueden acceder las acciones. - En qué contexto de seguridad se ejecutan las acciones. - Si las Acciones tienen recuperación Knowledge u otras funciones que pueden incorporar datos confidenciales o restringidos en la sesión de agente. Para configurar la colaboración y visibilidad efectivas en Salesforce: - **Diseñe el acceso a funciones de trabajo** significativas. Cree una matriz de seguridad que asigne sus [personas de usuario](/docs/architect/es-mx/well-architected/guide/secure#autenticación) a funciones de negocio que van a realizar. Utilice esta [plantilla](/docs/architect/es-mx/resources/guide/security-policy-template) como base para diseñar su colaboración y visibilidad. Para obtener más información sobre la identificación de funciones de negocio significativas, consulte [Unidades funcionales](/docs/architect/es-mx/well-architected/guide/composable#unidades-funcionales). - **Seleccione la ruta más sencilla para aplicar el principio de menor privilegio**. Cuando aplique el [principio de menor privilegio](/docs/architect/es-mx/well-architected/guide/secure#autorización) en el diseño de esquemas de colaboración y visibilidad, hágalo de la forma más sencilla. Evite esquemas de colaboración y restricciones de datos sobrediseñados, que pueden causar problemas descendentes para la capacidad de mantenimiento, la escalabilidad y la adaptabilidad del sistema. En su lugar, aproveche la colaboración de datos [flexible y estratificada en Salesforce](https://resources.docs.salesforce.com/latest/latest/en-us/sfdc/pdf/sharing_architecture.pdf) para configurar reglas precisas para el acceso de usuarios a nivel de datos. - **Establezca los valores predeterminados de toda la organización _interna_ (OWD) como Solo lectura pública, a menos que su negocio trate con datos confidenciales; luego utilice Privado**. Los OWD controlan el nivel de "menos" privilegios que tendrán los usuarios a nivel de datos. No puede restringir el acceso por debajo del nivel de su OWD. Aunque las OWD privadas pueden parecer ideales en cada caso de uso, los usuarios de todo el negocio a menudo pueden terminar replicando inadvertidamente una OWD más permisiva a través de esquemas de colaboración complejos. Además, las OWD privadas pueden provocar que los usuarios creen datos duplicados. Los cálculos de colaboración (y los nuevos cálculos) pueden tardar una cantidad significativa de tiempo en completarse dependiendo del volumen de datos y el sesgo principal-secundario o propiedad: las OWD privadas lo exacerban. Es importante tener en cuenta que los OWD no controlan los permisos CRUD y la visibilidad a nivel de campo. Solo seleccione una OWD de Privado cuando esté justificada por necesidades de negocio; la mayoría de las veces, dichas justificaciones estarán relacionadas con el [cumplimiento](/docs/architect/es-mx/well-architected/guide/compliant). - **Establezca los valores predeterminados de toda la organización (OWD) _externos_ en Privado, a menos que tenga una razón de negocio convincente para permitir un mayor acceso**. Las [OWD externas](https://help.salesforce.com/s/articleView?id=sf.security_owd_external.htm&type=5) se aplican a usuarios que acceden a datos de Salesforce desde sitios, portales, etc. de Experience Cloud. Esto le permite configurar líneas base de OWD separadas para usuarios internos y externos, para permitir diferentes tipos de privilegios “mínimos”. Establezca siempre el OWD para usuarios externos como Privado: las excepciones para un nivel más abierto deben justificarse claramente por necesidades de negocio. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/secure#patrones-y-antipatrones-de-seguridad-de-datos) a continuación muestra el aspecto adecuado (y deficiente) de la colaboración y la visibilidad en una organización de Salesforce. Utilice estos para validar sus diseños antes de construir o identificar oportunidades para mejoras adicionales. Para obtener más información acerca de las herramientas de colaboración y visibilidad de Salesforce, consulte [Herramientas relevantes para proteger](/docs/architect/es-mx/well-architected/guide/secure#herramientas-relevantes-para-proteger). ### Uso de cifrado El cifrado convierte datos legibles en un formato codificado indescifrable. Los datos cifrados pueden descifrarse o traducirse de nuevo a su forma original a través de una clave. Como resultado, el cifrado se encuentra entre los métodos más efectivos para proteger datos tanto en tiempo de inactividad como en tránsito, garantizando que incluso si partes no autorizadas acceden a los datos, serán ilegibles. Para diseñar para un uso adecuado del cifrado en sus soluciones de Salesforce: - **Siempre cifre adecuadamente los datos en tránsito**. Salesforce [emplea Seguridad de capa de transporte (TLS)](https://help.salesforce.com/s/articleView?id=sf.security_overview_infrastructure.htm&type=5) para todas las sesiones que tienen lugar en un [navegador compatible con](https://help.salesforce.com/s/articleView?id=sf.getstart_browser_overview.htm&type=5) Salesforce, y requiere que las llamadas salientes que utilizan HTTPS cumplan estándares de seguridad específicos. Las API de plataforma también emplean HTTPS de forma predeterminada. Además, los datos enviados entre un sitio de Salesforce Experience Cloud o un portal y su organización de Salesforce relacionada se cifran en tránsito [de forma predeterminada](https://help.salesforce.com/s/articleView?id=xcloud.security_pe_platform_encryption_faq.htm&type=5). Si utiliza los [servicios de email integrados](https://help.salesforce.com/s/articleView?id=sf.emailadmin_send_email_from_salesforce_overview.htm&type=5) de Salesforce, existen niveles predeterminados para la Seguridad de capa de transporte (TLS) que Salesforce utiliza para [enviar e intentar la entrega de email](https://help.salesforce.com/s/articleView?id=sf.emailadmin_deliverability.htm&type=5). Como mínimo, debe asegurarse de que la configuración de la organización no es inferior a la configuración predeterminada, a menos que tenga una justificación de negocio clara. Basándose en la clasificación y la confidencialidad de sus datos, considere aprovechar una conexión de red privada con Salesforce a través de AWS Direct Connect o Salesforce Private Connect. Esto garantiza que sus datos no atraviesen la Internet pública, sino que fluyan de forma segura a través de una conexión de red privada para el acceso de usuarios y las integraciones. - **Si el negocio lo requiere, cifre los datos en periodos de inactividad**. Salesforce ofrece diferentes formas de cifrar datos en periodos de inactividad. - **Hyperforce**. Los datos se cifran en tiempo de inactividad en organizaciones que utilizan [Hyperforce](/docs/architect/es-mx/fundamentals/guide/platform-multitenant-architecture#hyperforce). El cifrado se gestiona para su organización por Salesforce. No puede crear (o destruir) sus propias claves de cifrado. - **Salesforce Shield**. [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/) le permite cifrar datos en periodos de inactividad en una organización de Salesforce en capas adicionales, incluyendo las capas de aplicación y base de datos. Con Shield, tiene funciones de gestión completas para las claves de cifrado de su arrendatario, incluyendo sólidas opciones “Aportar su propia clave” (BYOK). También puede cifrar datos no estructurados (incluyendo archivos, archivos adjuntos, índices de búsqueda y eventos). Las instancias basadas en Hyperforce ofrecen la opción de utilizar un gestor de claves externas, lo que le permite aportar su propio KMS de AWS. Con esta función, mantiene el control completo sobre las claves de cifrado en su KMS que se utilizan para cifrar y descifrar los datos almacenados en Salesforce, lo que refuerza la seguridad y se alinea con los requisitos de cumplimiento de su organización. La lista de [patrones y antipatrones](/docs/architect/es-mx/well-architected/guide/secure#patrones-y-antipatrones-de-seguridad-de-datos) a continuación muestra el aspecto del uso adecuado (y deficiente) del cifrado en una organización de Salesforce. Utilice estos para validar sus diseños antes de construir o identificar oportunidades para mejoras adicionales. Para obtener más información acerca de las herramientas de cifrado disponibles en Salesforce, consulte [Herramientas relevantes para proteger](/docs/architect/es-mx/well-architected/guide/secure#herramientas-relevantes-para-proteger). ### Patrones y antipatrones de seguridad de datos Esta tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su corrección. ✨ Descubra más patrones para la seguridad de los datos en el [Explorador de patrones](/docs/architect/es-mx/well-architected-tools/guide/trusted-data-security) y antipatrones.

	Patrones	Antipatrones
Compartición y visibilidad	En sus estándares de diseño y documentación: - Una matriz de seguridad describe los datos a los que cada persona de usuario está autorizada a acceder - Se utilizan diferentes estándares de acceso a datos para usuarios externos y usuarios internos, si procede	En sus estándares de diseño y documentación: - Los estándares de diseño y la documentación no existen o no contienen una matriz de seguridad - Si existe una matriz de seguridad, no describe el acceso a datos para personas de usuario
	En su organización: - Los valores predeterminados de toda la organización (OWD) para usuarios internos es Lectura pública, o OWD para usuarios internos es Privado, debido a requisitos de cumplimiento - OWDs para usuarios externos es Privado - La IA generativa solo funciona en modo de usuario, o bien seleccionar usos para el acceso al sistema tiene una justificación de negocio clara	En su organización: - OWDs para usuarios internos se establece como Privado sin justificación de negocio o OWDs para usuarios internos se establece como Lectura/escritura pública - Los OWD para usuarios externos se establecen en cualquier cosa que no sea Privado sin justificación de negocio - La IA generativa funciona en modo sistema sin justificación de negocio
	En Apex: - Todos los códigos que acceden a datos (SOQL/SOSL) o realizan operaciones de datos (métodos DML/Clase de base de datos) se utilizan `con compartir` palabras clave	En Apex: - `con colaboración` las palabras clave se utilizan de forma incoherente
Uso del cifrado	En sus estándares de diseño y documentación: - Los casos de uso para cifrado de datos en tránsito y (si es necesario) en periodos de inactividad son claros y detectables - Los protocolos de cifrado aprobados están claramente enumerados - La documentación del código indica claramente dónde se utiliza el cifrado y qué protocolos se utilizan	En sus estándares de diseño y documentación: - Los protocolos de cifrado aprobados no están claros o no se enumeran - El código no está documentado o la documentación no es clara sobre dónde y cómo se utiliza el cifrado en el código
	En su organización: - Si se identifican riesgos de seguridad que requieren una mayor protección de datos en periodos de inactividad, ya sea Hyperforce o Salesforce Shield proporcionan cifrado en periodos de inactividad	En su organización: - Las necesidades de negocio requieren una mayor protección de datos en periodos de inactividad, pero no se utiliza Hyperforce ni Salesforce Shield
	En Apex: - Si las necesidades de negocio requieren una mayor protección de datos en tránsito, todo el código implicado en la integración lleva a cabo lógica utilizando métodos de criptoclase para cifrar datos antes de la transmisión o descifrar datos tras la recepción	En Apex: - Las necesidades de negocio requieren una mayor protección de datos en tránsito, pero el código implicado en la integración lleva a cabo lógica sin cifrar datos antes de la transmisión o en el momento de la recepción, o los métodos de Clase criptográfica se utilizan ad hoc

## Herramientas relevantes para proteger

Herramienta	Descripción	Seguridad organizativa	Seguridad de sesión	Seguridad de datos
Clase criptográfica Apex	Cifrar y descifrar datos en Apex			X
Control de acceso API	Gestionar el acceso a sus API de Salesforce y aplicaciones conectadas	X	X	X
Evento de anomalía de API	Realizar un seguimiento de anomalías en cómo realizan los usuarios llamadas de API		X
Configuración de seguridad del navegador	Proteger datos confidenciales y monitorear certificados SSL		X
Autenticación basada en certificado	Autenticar individuos con certificados digitales exclusivos	X	X
Certificados y claves	Verificar solicitudes a sitios web externos desde Salesforce		X	X
Escáner de código	Analizar código Apex para vulnerabilidades de seguridad		X	X
Aplicaciones conectadas	Integrar a través de API y protocolos estándar	X	X
Evento de relleno de credenciales	Realizar un seguimiento de intentos de inicio de sesión que utilizan credenciales de usuario robadas		X
Sitio de confianza de CSP	Evitar ataques de inyección de código (por ejemplo, secuencias de comandos de sitio cruzadas)		X
Flujos de inicio de sesión personalizados	Controlar procesos de negocio de inicio de sesión para usuarios	X
Identidad de cliente	Controlar los inicios de sesión y la verificación de sitios web y aplicaciones	X
Data Mask	Enmascarar automáticamente datos confidenciales en entornos sandbox			X
Registros de depuración	Realizar un seguimiento de eventos que se producen en su organización		X
Administración delegada	Asignar privilegios de administrador limitados a usuarios no administradores	X		X
Activación de dispositivo	Verificar inicios de sesión desde navegadores, dispositivos o intervalos de IP que no sean de confianza		X
Seguridad de transacciones mejorada	Interceptar eventos, monitorear y controlar la actividad de los usuarios		X
Acceso de campo	Controlar el acceso a los datos a nivel de campo			X
Seguimiento de auditoría de campo	Definir una política para retener datos de historial de campos archivados			X
Seguimiento del historial de campos	Realizar seguimiento y mostrar historial de campos			X
Frontdoor.jsp	Permitir el acceso con un Id. de sesión y URL de servidor existentes		X
Heroku Connect	Sincronización bidireccional entre Heroku y Salesforce			X
Heroku Shield	Crear aplicaciones compatibles con HIPAA o PCI			X
Seguridad de sesión de alta seguridad	Requerir seguridad adicional para operaciones confidenciales		X
Identity Connect	Asignar registros de usuario a cuentas de Active Directory	X
Historial de verificación de identidad	Auditar intentos de verificación de identidad de usuario	X
Licencia de usuario de integración	Otorgue acceso a datos y funciones solo a través de API.	X		X
Lightning Login	Evitar contraseñas débiles u olvidadas y cuentas bloqueadas	X
Acceso de inicio de sesión	Permitir a los usuarios de asistencia iniciar sesión como otro usuario	X
Iniciar sesión forense	Identificar comportamientos que pueden indicar fraude de identidad		X
Historial de inicios de sesión	Monitorear intentos de inicio de sesión de sitio de Experience Cloud y organización	X
Seguimiento de dispositivos móviles	Realizar un seguimiento y monitorear el acceso de dispositivos móviles a su organización		X
SDK móvil	Conectar con Salesforce Platform en aplicaciones móviles independientes	X	X	X
Monitorizar permisos de usuario (Shield)	Cambios de conjuntos de permisos y grupos de conjuntos de permisos	X		X
Autenticación de múltiples factores	Requerir dos o más métodos de verificación para iniciar sesión	X	X
Autenticación mutua	Aplicar autenticación mutua SSL o TLS
Mi dominio	Configurar políticas y páginas de inicio de sesión, inicios de sesión de SSO y redes sociales	X
Credenciales nombradas	Especificar direcciones URL de extremo y parámetros de autenticación		X
Autorización de OAuth	Autorizar el acceso a la aplicación cliente a través del intercambio de tokens	X
Políticas de contraseña	Establecer el historial, la longitud y la complejidad de la contraseña	X
Caducidades de asignación de conjuntos de permisos	Establecer vencimientos para asignaciones de conjuntos de permisos y grupos de conjuntos de permisos	X		X
Evento de conjunto de permisos	Monitorear cambios realizados en conjuntos de permisos y grupos de conjuntos de permisos	X		X
Grupos de conjuntos de permisos	Conjuntos de permisos de paquete para admitir requisitos de acceso complejos	X
Conjuntos de permisos	Controlar cómo acceden los usuarios a metadatos, funciones y aplicaciones	X
Conexión privada	Integraciones seguras entre Salesforce y Amazon Web Services			X
Perfiles	Controlar intervalos de direcciones IP de inicio de sesión y horas de inicio de sesión	X
Monitoreo de eventos en tiempo real	Monitorear y detectar eventos estándar en Salesforce		X
Configuración de sitio remoto	Registrar sitios externos para llamadas Apex o JavaScript		X
Evento de anomalía de reporte	Realizar un seguimiento de anomalías en el modo en que los usuarios ejecutan o exportan reportes		X
Reglas de restricción	Evitar que los usuarios accedan a registros innecesarios			X
Analizador de código de Salesforce	Escanee código a través de IDE, CLI o CI/CD para asegurarse de que se ajusta a las mejores prácticas		X	X
Reglas de ámbito	Controlar los registros predeterminados que pueden ver sus usuarios			X
Centro de seguridad	Visualice parámetros de seguridad en todas sus organizaciones y configure alertas para cambios de postura	X		X
Comprobación de estado de seguridad	Identificar vulnerabilidades en su configuración de seguridad			X
Evento de secuestro de sesión	Identificar acceso no autorizado a través de identificadores de sesión robados		X
Clase de gestión de sesiones	Personalizar la configuración de seguridad para una sesión activa		X
Configuración de seguridad de sesión	Configurar sesiones para proteger frente a ataques malintencionados		X
Configurar seguimiento de auditoría	Realizar un seguimiento de cambios de configuración recientes realizados por administradores			X
Configuración de colaboración	Controlar el acceso a datos a nivel de registro			X
Shield Platform Encryption	Cifrar datos confidenciales en periodos de inactividad y tránsito			X
Inicio de sesión único	Proporcionar acceso a múltiples aplicaciones a través de un único inicio de sesión	X	X
Sistema para Gestión de identidad entre dominios (SCIM)	Gestionar identidades entre sistemas a través de API de REST		X
Detección de amenazas	Utilizar estadísticas y aprendizaje automático para detectar amenazas		X
Intervalos de IP de confianza	Definir direcciones IP que no requieren verificación adicional		X
Reporte de acceso de usuario	Obtener una vista unificada del objeto, el registro y el acceso de permisos de sus usuarios	X		X

## Recursos relevantes para proteger

Recurso	Descripción	Seguridad organizativa	Seguridad de sesión	Seguridad de datos
Una guía para compartir arquitectura	Obtenga más información acerca de herramientas de acceso, modelos de colaboración y casos de uso			X
Plantilla de estándares de diseño	Crear estándares de diseño para su organización	X	X	X
Cómo construir un modelo de seguridad de usuario	Obtener una mejor comprensión de modelos de seguridad de usuario	X		X
Cómo implementar el principio de menor privilegio en Salesforce	Aprenda a aplicar controles de acceso a datos de PoLP en Salesforce	X		X
Monitorizar sesiones de usuario	Revisar sesiones activas y finalizar sesiones sospechosas		X
Autenticación de múltiples factores	Acceder a recursos oficiales de MFA desde Salesforce	X
Grupos de conjuntos de permisos (Trailhead)	Ponerse manos a la obra con grupos de conjuntos de permisos	X		X
Arquitectura de API REST	Comprender términos y conceptos de API de REST	X	X	X
Seguridad y API de SOAP	Comprender términos y conceptos de API de SOAP	X	X	X
Mejores prácticas de seguridad para usuarios de API y del sistema interno	Acceso seguro a Salesforce por usuarios de API y usuarios de sistema internos seguros	X
Guía de implementación de seguridad	Echar un vistazo integral a Seguridad de Salesforce	X	X	X
Plantilla de política de seguridad	Establecer políticas de seguridad para su organización	X	X	X
Tipos de sesión	Identificar los tipos de sesiones utilizadas para acceder a su organización		X
Fundamentos de modelado de amenazas (Trailhead)	Obtenga información acerca de amenazas de seguridad y cómo evitarlas.		X