Operational Excellence - Patrones de automatización


Obtenga más información acerca de Excelencia operativa bien arquitectónica → Automatización y eficiencia

Patrones

Dónde buscarQué aspecto tiene
Plataforma | Tableros✅ Todas las mediciones relacionadas con los KPI están incluidas en al menos un tablero
Plataforma | Documentación✅ Las salidas para cada automatización son mensurables y están sujetas a plazos
Plataforma | Documentación✅ Las partes interesadas responsables se enumeran para cada KPI

Antipatrones

Dónde buscarAspecto negativo
Plataforma | Tableros⚠️ La creación de reportes de KPI no existe o faltan tableros de mediciones relacionadas con algunos KPI
Plataforma | Documentación⚠️ Existen indicadores clave de desempeño sin partes interesadas responsables
Plataforma | Documentación⚠️ Los KPI no existen para automatizaciones o tienen plazos poco claros para mediciones

Patrones

Dónde buscarQué aspecto tiene
Plataforma | Flujo✅ Flow Builder se utiliza para la automatización desencadenada por registros (sustitución de Process Builder y reglas de flujo de trabajo)
Plataforma | Flujo✅ Los flujos desencadenados por registros con ejecución antes del guardado se utilizan para la población de campos antes de la creación de registros
Plataforma | Flujo✅ Los flujos gestionan lógica de decisiones, bucles, llamadas de API, operaciones DML y orquestación compleja de múltiples pasos
Plataforma | Flujo✅ El control de transacciones de flujo se utiliza para confirmar cambios intermedios cuando es necesario
Plataforma | Flujo✅ La gestión de fallos está implementada para una recuperación de errores elegante en flujos
Plataforma | Flujo✅ Los flujos de pantalla reactivos proporcionan experiencias de usuario dinámicas
Plataforma | Flujo✅ La automatización declarativa se selecciona cuando los usuarios de negocio o administradores necesitan modificar la lógica sin la participación del desarrollador
Plataforma | Flujo✅ Las variables no hacen referencia a valores codificados (para tipos de registro, usuarios, etc.)
Plataforma | Flujo✅ Lógica de transferencia de flujos a Apex en contextos de gran volumen de datos
Plataforma | Flujo✅ Los flujos secundarios se utilizan para secciones de procesos que necesitan reutilizarse en todo el negocio
Plataforma | Flujo✅ Todos los flujos iniciados automáticamente utilizan elementos de decisión y/o pausa para evaluar criterios de entrada y evitar bucles infinitos o ejecuciones en grandes volúmenes de datos
Plataforma | Flujo✅ Solo se solicita a los usuarios proporcionar datos cuando no se pueden utilizar datos del sistema existentes
Plataforma | Flujo✅ Los flujos están organizados en una estructura jerárquica que consta de un flujo principal y subflujos de soporte
Plataforma | Flujo✅ Todas las entradas de usuario tienen un propósito claro dentro del flujo
Plataforma | Flujo✅ Cada flujo sirve a un único propósito específico
Plataforma | Flujo✅ Cada paso realiza una tarea granular específica
Plataforma | Flujo✅ Todos los flujos iniciados en contexto de usuario abstraen transacciones de contexto del sistema en subflujos, colocados coherentemente después del elemento Pausa para crear una nueva transacción
Plataforma | Flujo✅ Todos los flujos desencadenados por registros tienen valores de orden de desencadenador rellenados
Plataforma | Flujo✅ Los flujos que implican llamadas del sistema externo o procesos de larga ejecución utilizan rutas asíncronas
Plataforma | Flujo✅ Se crean secuencias complejas de operaciones de datos relacionadas con Orchestrator (en vez de invocar múltiples subflujos dentro del flujo monolítico)
Plataforma | Validación✅ La integridad de los datos se aplica a nivel de plataforma utilizando reglas de validación, reglas de duplicados y campos obligatorios
Plataforma | Validación✅ Las reglas de validación evitan el ingreso de datos no válidos antes de guardar (más eficiente que la validación de desencadenadores)
Plataforma | Procesos de aprobación✅ El enrutamiento de aprobación de múltiples pasos gestiona rutas de aprobación paralelas y secuenciales con aprobadores delegados
Plataforma | Procesos de aprobación✅ La arquitectura de aprobación tiene en cuenta escenarios de excepción (todos los aprobadores de vacaciones, requisitos de negocio urgentes omitiendo la aprobación normal)

Antipatrones

Dónde buscarAspecto negativo
Plataforma | Flujo⚠️ Process Builder y reglas de flujo de trabajo utilizados para la nueva automatización (Flow Builder es la dirección estratégica)
Plataforma | Flujo⚠️ Automatización programática utilizada cuando los usuarios de negocio o administradores necesitan modificar la lógica sin la participación del desarrollador
Plataforma | Flujo⚠️ Los flujos carecen de gestión de fallos dando como resultado una mala recuperación de errores
Plataforma | Flujo⚠️ Las variables tienen valores codificados
Plataforma | Flujo⚠️ Los flujos deben desactivarse manualmente antes de cargas de datos masivas
Plataforma | Flujo⚠️ Partes de un flujo se repiten entre flujos en vez de utilizar subflujos
Plataforma | Flujo⚠️ Los flujos desencadenan avisos de “excepción no gestionada”
Plataforma | Flujo⚠️ Incluso flujos sencillos causan regularmente errores relacionados con límites reguladores
Plataforma | Flujo⚠️ Los flujos requieren entradas adicionales para proporcionar contexto
Plataforma | Flujo⚠️ Los flujos sirven para múltiples fines
Plataforma | Flujo⚠️ Los grupos de pasos relacionados contienen funciones que se solapan con grupos de pasos en otros flujos
Plataforma | Flujo⚠️ Los flujos solicitan entradas de usuario cuando se pueden utilizar datos almacenados en su lugar
Plataforma | Flujo⚠️ Los flujos requieren entradas cuyos datos no se utilizan
Plataforma | Flujo⚠️ Realización de DML utilizando recopilación que se genera desde componente de pantalla (aprovechando la configuración “Utilizar los Id. y todos los valores de campo desde un registro o recopilación de registros” en crear, actualizar o eliminar elemento cuando se genera recopilación desde componente de pantalla)
Plataforma | Flujo⚠️ 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
Plataforma | Flujo⚠️ Rutas asíncronas no utilizadas de forma coherente o en absoluto
Plataforma | Flujo⚠️ Los flujos grandes y monolíticos intentan coordinar secuencias complejas de operaciones de datos relacionadas (con o sin subflujos)
Plataforma | Procesos de aprobación⚠️ La arquitectura de aprobación no tiene en cuenta escenarios de excepción (todos los aprobadores de vacaciones, requisitos de negocio urgentes)
Plataforma | Validación⚠️ Integridad de datos aplicada solo en desencadenadores en vez de reglas de validación (validación de desencadenadores menos eficiente y más compleja)

Patrones

Dónde buscarQué aspecto tiene
Plataforma | Apex✅ El marco de trabajo del controlador de desencadenadores aplica la función de desencadenador único por objeto, masificación, separación de problemas y prevención de ejecuciones recursivas
Plataforma | Apex✅ Los controladores de desencadenadores delegan en clases de servicio para lógica de negocio, manteniendo una clara separación de preocupaciones
Plataforma | Apex✅ Los desencadenadores utilizan protección de recursión utilizando indicadores estáticos o clase de control de recursión exclusiva
Plataforma | Apex✅ Apex futuro se utiliza con moderación, para llamadas o DML de objetos del sistema
Plataforma | Apex✅ Las invocaciones Apex asíncronas utilizan DML complejo Colocable en cola para ‘encadenar’ entre transacciones
Plataforma | Apex✅ Apex por lotes se utiliza para grandes volúmenes de datos (procesa grandes cantidades de datos con límites reguladores exclusivos por fragmento)
Plataforma | Apex✅ Los trabajos por lotes tienen una gestión de errores que registra registros con fallos sin detener la ejecución de lotes completa
Plataforma | Apex✅ La API masiva se utiliza solo cuando se deben procesar grandes cantidades de datos (las API de SOAP y REST nativas se aprovechan para cantidades más pequeñas de datos)
Plataforma | Apex✅ Apex colocable en cola se utiliza para orquestación de flujos de trabajo complejos, llamadas externas con lógica de reintento y procesamiento que se benefician de límites asíncronos
Plataforma | Apex✅ Apex programado ejecuta el procesamiento en programaciones fijas para mantenimiento nocturno, creación de reportes diarios, sincronización de integración periódica y reglas de negocio basadas en tiempo
Plataforma | Estándares de diseño✅ Los casos de uso para operaciones síncronas y asíncronas en automatizaciones se describen claramente como parte de estándares de diseño
Plataforma | Documentación✅ Las rutas de ejecución planificadas y potenciales para automatizaciones se describen claramente

Antipatrones

Dónde buscarAspecto negativo
Plataforma | Apex⚠️ Múltiples desencadenadores en un objeto con orden de ejecución impredecible y lógica solapada
Plataforma | Apex⚠️ Lógica de negocio incrustada directamente en archivos de desencadenador dificultando las pruebas
Plataforma | Apex⚠️ Sin marco de trabajo del controlador de desencadenadores o patrones de desencadenadores incoherentes entre objetos
Plataforma | Apex⚠️ Los trabajos Apex por lotes tienen un tamaño de ámbito muy pequeño (por ejemplo, tamaño de ámbito = 1)
Plataforma | Apex⚠️ Apex por lotes utilizado para llamadas externas (grandes volúmenes de datos de Salesforce enviados al sistema externo utilizando Apex por lotes)
Plataforma | Apex⚠️ Funciones Apex asíncronas utilizadas arbitrariamente (Métodos futuros y Apex colocable en cola utilizados de forma incoherente o indistinta)
Plataforma | Apex⚠️ Apex asíncrono rara vez utilizado
Plataforma | Apex⚠️ 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
Plataforma | Estándares de diseño⚠️ Los casos de uso para operaciones síncronas y asíncronas no se solucionan
Plataforma | Documentación⚠️ La invocación de automatización no está documentada

Patrones

Dónde buscarQué aspecto tiene
Plataforma | Eventos de plataforma✅ Eventos de plataforma se utilizan para la automatización dirigida por eventos que desvincula publicadores de suscriptores
Plataforma | Eventos de plataforma✅ Los publicadores no están al tanto de suscriptores y publican fuego y olvido
Plataforma | Eventos de plataforma✅ Múltiples suscriptores reaccionan independientemente a eventos a través de flujos desencadenados por eventos de plataforma, desencadenadores Apex o integraciones externas
Plataforma | Eventos de plataforma✅ Los Id. de reproducción se utilizan para reproducir eventos perdidos desde cualquier punto en el plazo de retención de 72 horas
Plataforma | Eventos de plataforma✅ Eventos de plataforma activa la comunicación entre organizaciones, la notificación del sistema externo y la orquestación de flujos de trabajo internos

Antipatrones

Dónde buscarAspecto negativo
Plataforma | Eventos de plataforma⚠️ Acoplamiento directo entre publicadores y suscriptores evitando la automatización componible
Plataforma | Eventos de plataforma⚠️ La actualización del nivel de cuenta llama directamente a la actualización de oportunidades, la notificación del equipo de cuentas y la sincronización del almacén de datos en una transacción (el acoplamiento ajustado requiere cambios en la lógica de la cuenta cada vez que se necesita un nuevo procesamiento descendente)
Plataforma | Apex⚠️ Publicar inmediatamente Eventos de plataforma utilizados adhoc (eventos en tiempo real utilizados en vez de Publicar después de confirmar independientemente de los requisitos de pedidos de publicación o los riesgos de bloqueo de registros)

Patrones

Dónde buscarQué aspecto tiene
Plataforma | Apex✅ Las declaraciones SOQL utilizan operadores de comparación de lógica positiva (INCLUDES, IN) como lógica principal o única
Plataforma | Apex✅ SOQL evita = NULL, != NULL o los utiliza con moderación después de operadores de comparación positivos
Plataforma | Apex✅ SOQL no utiliza declaraciones de LIMIT 1
Plataforma | Apex✅ SOQL no utiliza la palabra clave ALL ROWS
Plataforma | Apex✅ SOQL no aparece en bucles
Plataforma | Apex✅ Los criterios comodín aparecen en SOSL (no SOQL)
Plataforma | Apex✅ Las declaraciones SOQL evitan comparaciones de LIKE o comparaciones de texto parcial
Plataforma | Apex✅ SOQL está envuelto en bloques de try-catch
Plataforma | Apex✅ Las variables no hacen referencia a valores codificados (para tipos de registro, usuarios, etc.)
Plataforma | Apex✅ Cada clase sirve a un único propósito específico
Plataforma | Apex✅ Cada método realiza una tarea granular específica
Plataforma | Apex✅ Todas las variables de entrada tienen un propósito claro dentro de la clase
Plataforma | Apex✅ La ejecución de código requiere un número mínimo de recursos

Antipatrones

Dónde buscarAspecto negativo
Plataforma | Apex⚠️ Las declaraciones SOQL utilizan NOT, criterios de NOT IN como operador principal o único operador de comparación (no selectivo)
Plataforma | Apex⚠️ Las declaraciones SOQL utilizan la palabra clave ALL ROWS (no selectiva)
Plataforma | Apex⚠️ Las declaraciones SOQL utilizan = NULL, criterios de != NULL como operador principal o único operador de comparación (no selectivo)
Plataforma | Apex⚠️ Las variables tienen valores codificados
Plataforma | Apex⚠️ SOQL aparece dentro de bucles
Plataforma | Apex⚠️ Las declaraciones SOQL utilizan criterios de filtro de LIKE y comodines con frecuencia (no selectivo)
Plataforma | Apex⚠️ SOQL no incluido en bloques de try-catch
Plataforma | Apex⚠️ Las declaraciones SOQL utilizan LIMIT 1 (no selectivo)
Plataforma | Apex⚠️ SOSL rara vez o no se utiliza coherentemente para criterios de selección de comodines
Plataforma | Apex⚠️ Las clases sirven para múltiples fines
Plataforma | Apex⚠️ 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
Plataforma | Apex⚠️ Las variables de entrada no se utilizan actualmente en métodos
Plataforma | Apex⚠️ Los métodos recuperan innecesariamente datos de la base de datos o de sistemas externos

Patrones

Dónde buscarQué aspecto tiene
Plataforma | Apex✅ Las excepciones personalizadas se utilizan para crear lógica y mensajería de error avanzada
Plataforma | Apex✅ El código encierra todos los pasos de proceso DML, SOQL, llamadas y otros pasos críticos en bloques de try-catch
Plataforma | Apex✅ Los métodos de clase de base de datos pueden utilizarse exclusivamente para todas las operaciones de datos (en vez de DML)
Plataforma | Apex✅ En contextos asíncronos y masivos, se utilizan métodos de clase Base de datos en vez de DML
Plataforma | Aura✅ JavaScript encierra todas las operaciones de datos y pasos de procesos críticos en bloques de try-catch
Plataforma | Aura✅ Dentro de los bloques de try-catch, el Error JavaScript nativo se utiliza en declaraciones throw (sin uso de $A.error())
Plataforma | Aura✅ Toda la lógica de error recuperable aparece en declaraciones de catch y proporciona mensajes de usuario claros
Plataforma | Flujo✅ Los flujos con operaciones de datos, llamadas y otra lógica de procesamiento crítica tienen rutas de fallo para todas las acciones clave
Plataforma | Flujo✅ Los flujos de pantalla utilizan de forma coherente conectores de fallos para mostrar errores a los usuarios
Plataforma | Flujo✅ Los mensajes de error personalizados están configurados para errores que aparecerán en pantalla
Plataforma | Componentes web Lightning (LWC)✅ JavaScript encierra todas las operaciones de datos y pasos de procesos críticos en if ()/else if () bloques
Plataforma | Componentes web Lightning (LWC)✅ Todas las funciones de @wire utilizan propiedades de data y error proporcionadas por la API
Plataforma | Componentes web Lightning (LWC)✅ Todas las if (error) /else if (error) declaraciones contienen lógica para procesar errores y proporcionar mensajes informativos

Antipatrones

Dónde buscarAspecto negativo
Plataforma | Apex⚠️ DML, SOQL, llamadas u otros pasos de procesos críticos no incluidos de forma coherente en bloques de intento de captura
Plataforma | Apex⚠️ No se utilizan métodos de clase Base de datos
Plataforma | Apex⚠️ Operaciones de datos realizadas exclusivamente con DML
Plataforma | Apex⚠️ Las declaraciones de System.debug aparecen en código de producción (y no se comentan)
Plataforma | Aura⚠️ JavaScript no encierra de forma coherente operaciones de datos y pasos de procesos críticos en bloques de try-catch
Plataforma | Aura⚠️ Los componentes utilizan $A.error()
Plataforma | Aura⚠️ La lógica de error recuperable no aparece coherentemente en declaraciones de catch, y los mensajes de error a usuarios no son claros
Plataforma | Flujo⚠️ Los flujos no utilizan rutas de fallo de forma coherente o en absoluto
Plataforma | Flujo⚠️ Mensajes de error personalizados no utilizados, de modo que los usuarios ven el mensaje predeterminado “Se produjo un fallo no gestionado en este flujo”
Plataforma | Componentes web Lightning (LWC)⚠️ Las funciones de @wire no utilizan propiedades de data y error proporcionadas por la API (o no las utilizan de forma coherente)
Plataforma | Componentes web Lightning (LWC)⚠️ Si se utiliza en absoluto, las declaraciones if (error)/else if (error) no contienen realmente lógica para procesar errores y proporcionan mensajes de error útiles
Plataforma | Componentes web Lightning (LWC)⚠️ JavaScript no utiliza de forma coherente if ()/else if () bloques con operaciones de datos o pasos de procesos críticos