Este texto se tradujo utilizando el sistema de traducción automatizado de Salesforce. Realice nuestra encuesta para proporcionar comentarios sobre este contenido e indicarnos qué le gustaría ver a continuación.
Lea sobre nuestras programaciones de actualizaciones aquí.
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 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.
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 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 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.
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) 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)
- Tiene resultados claramente definidos y mensurables (consulte 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)
- 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)
- Proporciona opciones de entrada que los usuarios pueden comprender sin necesidad de saber cómo funcionan los sistemas subyacentes (Consulte útil)
La lista de patrones 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.
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 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 y 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. SOQL puede incluso pasar un indicador DML explícito 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, 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 para obtener más consideraciones sobre el diseño de operaciones de sincronización/asíncronas.
La lista de patrones 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.
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 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.
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 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 |
| 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 |
| 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 |
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 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 ya proporcionados por Salesforce y no utilizar la funcionalidad estándar 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.
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. Esto incluye comprender el orden de ejecución 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 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 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).
- 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 y utilice operaciones asíncronas para todas las acciones después de contextos.
- Utilice mensajería y notificaciones 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. 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 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). 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”.
- Lógica que debe ejecutarse en contexto de usuario o sistema
- Salesforce Platform aplica la 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 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 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 asíncronos, rutas asíncronas o acciones invocables).
- 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, utilizando métodos Apex asíncronos.
La lista de patrones y antipatrones 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.
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.
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 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). En su lugar, cada automatización en el sistema debe tener la capacidad de conectar con los componentes 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 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.
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 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" |
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, 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.
| 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 |
| 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 |
Ayúdenos a mantener Salesforce Well-Architected relevante para usted; realice nuestra encuesta para proporcionar comentarios sobre este contenido e indicarnos qué le gustaría ver a continuación.