Nuestros investigadores estrellas han agotado sus depósitos de café, por su búsqueda noche y día por la resolución, hasta que Selena encontró el resultado en GitHub así que hoy la comparte con nosotros.
Solución:
Los ajustes personalizados están disponibles tanto en Workflows como en Triggers. Si crea un objeto de configuración personalizada “Jerarquía” con una casilla de verificación, puede hacer referencia a esa casilla de verificación para habilitar o deshabilitar la validación o el código. El diseño de la jerarquía le permitiría establecer valores predeterminados en todo el sistema y luego anular a los usuarios individuales según sea necesario. Ha sido bastante efectivo en varias ocasiones.
Hasta la fecha, no hay una funcionalidad lista para usar disponible en Salesforce para gestionar la activación y desactivación del flujo de trabajo, el activador y/o la validación en un solo paso.
Lo que hemos hecho es, como ya explicaste para Workflow and Validation, usar etiquetas personalizadas.
Para Triggers, hemos creado configuraciones personalizadas que tienen dos campos: “Nombre lógico” y “isEnabled”.
Seguimos un disparador en un diseño de objeto, por lo que es posible que se use un solo disparador para ejecutar múltiples operaciones.
En Triggers, antes de ejecutar cualquier bloque de código, verificamos si la Lógica para esa funcionalidad está habilitada o no en la configuración personalizada. Entonces, solo desde la configuración personalizada, controlamos la ejecución de Trigger.
La mejor manera que he visto para manejar esto es, de hecho, crear previamente sus reglas de validación y otra lógica con algún interruptor incorporado. Las etiquetas personalizadas son probablemente las más adecuadas para esto si desea activar/desactivar la validación de forma universal; las configuraciones personalizadas encajarían perfectamente (ya que pueden ser globales o de ámbito de usuario) pero no puede acceder a ellas convenientemente en varios lugares. He visto varios otros enfoques como el rol de usuario o el nombre de usuario, pero esos son más frágiles.
El problema, por supuesto, es que necesita construir su organización desde cero con esto en mente, o actualizar esta lógica en cientos de lugares. Pero es una necesidad tan común que te acostumbrarás a ponerlo en todas partes.
Si su lógica lo justifica, le recomiendo incorporar más que un interruptor de encendido y apagado: incorpore una serie de niveles de “apagado” para que pueda descender con elegancia al nivel de lógica que necesita cuando se cargan los datos. Casi no le costará más por adelantado, pero estará agradecido. Si usa configuraciones personalizadas, querrá algo compatible con los controles CONTIENE. por ejemplo, “123456789” = todas las comprobaciones están activadas. Pero eliminar “9” hace que se deshabiliten algo como todas las notificaciones de correo electrónico y chat, “8” deshabilita algo como las reglas de validación “suaves”, y todas ellas tienen comprobaciones como
if (Label.myLabel.contains('9')) { // do my stuff
IF(CONTAINS($Label.myLabel, "8"), [fire my semi-optional user-facing validation rule], [auto-pass my rule])
La desventaja de las etiquetas personalizadas, por supuesto, es que tendrán efectos en todo el sistema para todos los usuarios, lo que no funcionará para muchos clientes. En esos casos, probablemente sea mejor usar un solo usuario, rol o perfil en estas reglas (ya sea una cuenta de API dedicada o un usuario/rol/perfil de administrador del sistema) y hacer el mismo tipo de verificación con algo como nombre de usuario o rol. Y luego usar el contenido de algo como el alias de usuario si desea un control granular de encendido/apagado.
Reseñas y calificaciones de la guía
Tienes la opción de añadir valor a nuestro contenido colaborando tu veteranía en las interpretaciones.