La automatización durante la carga

🌐 También en 19 idiomas

English · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

Imagen generada con IA

Traducido con IA. Aún no revisado por la comunidad. Leer en inglés Esta sección cambió en inglés y aún no se ha vuelto a traducir. (8)

Módulo 3 de 5 del capítulo Migración y sincronización, capítulo 10 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: Cargar con volumen · Siguiente: El fin de semana de corte

La pregunta que responde este módulo: ¿qué debería pasar con la automatización de Salesforce mientras se cargan los datos de la migración?

Los registros de RouteDesk están listos: unos 707.000, preparados, ordenados por padre, ensayados. Empiezas la carga y Salesforce empieza a hacer exactamente lo que lo configuraste para hacer. Los flujos se disparan, los desencadenadores se ejecutan, las reglas de validación se evalúan, se envían correos, se crean tareas, se calculan resúmenes, se lanzan integraciones, se publican eventos. Tu migración de 707.000 registros ya no realiza 707.000 operaciones. Realiza 707.000 registros multiplicados por todo lo que provoca cada registro. Es otra migración.

Empieza por el dibujo

Aquí está otra vez el panorama, el fin de semana en que se retira RouteDesk. La flecha de la migración está en ámbar. Ahora mira qué más sale de Salesforce cuando se crea una orden de trabajo o cambia su estado.

Clic para ampliar

Una flecha de entrada. Tres flechas más de salida, por cada registro, salvo que decidamos otra cosa.

Cada una de esas flechas se diseñó en el capítulo 9 para una entrega que acaba de ocurrir: cambió un estado, así que avisa al socio y a Snowflake; terminó una entrega, así que cuéntala para facturar; hay una entrega mañana, así que envía un mensaje al destinatario. La carga crea 196.400 órdenes de trabajo en un fin de semana, y unas 190.000 llegan ya completadas. Para la automatización, cada una parece una entrega que acaba de ocurrir.

La automatización no sabe que es una migración

Salesforce ve una transacción de registro. No sabe que “esto son datos históricos cargados durante un corte controlado”. Un flujo ve una cuenta nueva y hace aquello para lo que se construyó: crea una tarea de bienvenida, envía un correo de bienvenida, publica un evento, actualiza un registro relacionado, llama a otro sistema. Correcto cuando un comercial crea una cuenta un martes por la tarde. Completamente equivocado cuando una migración crea 800.000 cuentas históricas un sábado por la noche. La misma operación, distinto contexto de negocio. En Steve Trucking, una orden de trabajo que llega con el estado Completed se parece exactamente a un equipo que terminó una entrega hace cinco minutos.

Así que, para una migración importante, parto de esto: la automatización normal de negocio no debería ejecutarse a ciegas contra la carga. Eso no significa “desactívalo todo”. Significa que cada automatización importante recibe una decisión deliberada, y no quiero descubrir la respuesta porque producción envió 400.000 correos.

Tres opciones: no la necesites, simúlala, aplázala

Para cada automatización, pregunto qué hace y qué pasa si no se ejecuta, y luego la pongo en una de tres categorías.

No la necesitas (elimínala). El comportamiento no debería ocurrir para los registros migrados. Los clientes que tenemos desde hace ocho años no necesitan un “¡Bienvenido a nuestra empresa!”. Inserta una cuenta y envía un correo; carga un millón de cuentas, y no necesito un millón de correos.

Simúlala. La automatización no debería ejecutarse, pero el resultado que crea sigue siendo necesario. Un flow en la creación de cuentas deriva el segmento de cliente. Las cuentas migradas necesitan un segmento válido, pero ejecutar el flow completo cinco millones de veces es caro o tiene efectos secundarios. Así que calculamos el segmento en la transformación y cargamos el resultado. No ignoramos la regla de negocio; hicimos en la carga el trabajo de la automatización.

Aplázala. El resultado es necesario, pero no dentro de la transacción de carga. Carga con la automatización desactivada y una marca establecida, y luego lanza un proceso por lotes para ponerse al día: recalcular, crear los registros dependientes, publicar lo que necesitan los sistemas posteriores. Aplazar puede hacer la carga más rápida y más controlable sin renunciar al resultado.

Y a veces la dejas activada. En una carga más pequeña, en la que el negocio quiere que se ejecute su proceso normal, deja que el sistema haga lo que hace. Eso también es una elección, siempre que sea una elección.

Elijas lo que elijas, esta es la regla que enseño: cada vez que desactivas una automatización, asumes toda la responsabilidad de que esa lógica de negocio no ocurra. Necesitas entender cada automatización antes de decidir.

Clic para ampliar

Tres preguntas, cuatro respuestas, una decisión por automatización.

Conocimiento para el examen. Para cada automatización en una carga grande, decide: no se necesita para los datos migrados (desactívala con un bypass), se necesita pero su resultado se puede fijar en los datos (simúlala en la transformación), se necesita pero no dentro de la carga (aplázala a un lote posterior), o se necesita dentro de la carga (déjala ejecutarse). Espera un escenario en el que ejecutar la automatización a ciegas crea correos, tareas o llamadas de integración no deseados, y otro en el que desactivarla pierde en silencio un resultado necesario.

“Desactivar la automatización” no es toda la estrategia

El plan dice “desactivar la automatización”. ¿Qué automatización? ¿Cómo, quién, cuándo? ¿Cómo sabemos que está desactivada, y cómo sabemos que vuelve a estar activada? ¿Qué resultados que produce normalmente deben seguir existiendo después? ¿Qué pasa si hay usuarios en el sistema mientras está desactivada, o si la migración falla a medias? Desactivar algo es una acción operativa. La arquitectura necesita todo el ciclo de vida: estado normal, estado de migración, vuelta a la normalidad y prueba de que volvimos.

Y antes de decidir qué desactivar, averigua qué sigue activado. La automatización antigua también se ejecuta sobre los registros migrados. Salesforce dejó de dar soporte a Workflow Rules y Process Builder el 31 de diciembre de 2025, pero “tus Workflow Rules y procesos de Process Builder activos siguen ejecutándose como antes” (Retirada de Reglas de flujo de trabajo y Process Builder (se abre en una pestaña nueva), Salesforce Help, consultado el 2026-10-27). Well-Architected señala el coste: una organización que “arrastra docenas de Process Builders que quedaron de implementaciones anteriores … paga por evaluar cada uno de ellos en cada guardado de registro relevante”, y su consejo es “migrar los Process Builders que quedan a Flow; no limitarse a desactivarlos” (Resource and Cost Optimization (se abre en una pestaña nueva), consultado el 2026-10-27). Una migración es una buena razón para eliminarlos primero, para que 707.000 registros no pasen por una automatización que nadie recuerda.

Incorpora el bypass desde el principio

Mi posición más firme: la automatización importante debería tener un bypass controlado aunque no haya ninguna migración prevista. La migración no es el único motivo por el que lo necesitarás. Grandes correcciones, reparación de datos, rellenos retroactivos, reparación de integraciones, recuperación de emergencia: a veces tienes que ejecutar una operación controlada sin todas las piezas de la automatización normal. Si la única forma es editar el flow en producción, desactivar el trigger o borrar una regla de validación, hemos hecho innecesariamente peligroso el trabajo operativo. Y no puedes simplemente desactivar un trigger en producción: eso es un despliegue, con sus pruebas.

La respuesta habitual es un bypass (algunos equipos lo llaman interruptor de emergencia): lo primero que hace el desencadenador o el flujo es comprobar un interruptor, y saltarse a sí mismo si el interruptor está activado. Decide el alcance: un interruptor global para toda la organización, uno por objeto, uno por automatización o uno para usuarios concretos, como el usuario de carga de datos o cualquiera que tenga un permiso. Ponlo en tus flujos además de en tus desencadenadores. Los flujos son fáciles de desactivar, pero un interruptor por usuario permite que todos los demás sigan trabajando. Considero los flujos programación visual: tanto si escribes código como si programas visualmente, sigues programando, y los programas necesitan esto.

Y esta es la parte que los equipos pasan por alto: el bypass forma parte del diseño original. No es algo que construyes la semana en que lo necesitas. Cada desencadenador y cada flujo recibe su bypass cuando se construye por primera vez. Se prueba en los dos sentidos, activada y desactivada, como cualquier otro comportamiento. Y va a producción con la automatización, mucho antes de cualquier migración, así que el fin de semana del corte ya está ahí, ya probada y lista para activarse. Un bypass escrito a toda prisa para la carga es código nuevo y sin probar que entra en producción el fin de semana más arriesgado del proyecto. La guía de decisión de Salesforce sobre Record-Triggered Automation es igual de firme: “Una organización de Salesforce bien diseñada necesita un mecanismo coherente y fiable para desactivar la automatización. No es una función opcional, sino un requisito operativo básico” (Record-Triggered Automation (se abre en una pestaña nueva), guía de decisión de Salesforce Architects, consultado el 2026-10-27).

Salesforce dice lo mismo con sus propias palabras. Su lista Well-Architected de antipatrones de automatización incluye “Los flujos deben desactivarse manualmente antes de las cargas masivas de datos” (Automation Patterns (se abre en una pestaña nueva), Operational Excellence, consultado el 2026-10-27). Si tu plan de carga dice “desactivar estos doce flujos el viernes por la noche”, ese es el antipatrón.

Conocimiento para el examen. Incorpora un bypass en los desencadenadores y los flujos cuando se construyen por primera vez (una comprobación de un permiso personalizado, una configuración personalizada o metadatos personalizados al principio), pruébala activada y desactivada e impleméntala con antelación, para que las cargas grandes puedan saltárselos sin editar ni desactivar nada en producción. Delimita su alcance: por objeto, por automatización o por usuario, como el usuario de migración. Desactivar flujos a mano antes de una carga masiva es un antipatrón según la propia guía Well-Architected de Salesforce.

Cómo es un bypass

Entonces, ¿cómo es en realidad un bypass? Tres partes: un lugar donde guardar el interruptor, una comprobación al principio de cada desencadenador y cada flujo, y la misma comprobación en las reglas de validación que decidas relajar. Salesforce te da tres lugares donde guardarlo, y cada uno decide a quién se aplica el interruptor.

Dónde vive el interruptor	A quién se aplica	Para qué sirve
Un permiso personalizado, concedido mediante un conjunto de permisos	Solo a los usuarios que lo tienen	El bypass habitual en una migración: dáselo al usuario de migración para la carga y quítaselo después
Una configuración personalizada de jerarquía	A toda la organización, a un perfil o a un usuario	Un “automatización desactivada” global para todos, o un interruptor para un perfil o un usuario
Un registro de metadatos personalizados por automatización	A todos, para esa automatización	Desactivar una automatización concreta, implementada y versionada como el código

La configuración personalizada de jerarquía es la que cubre lo global, el perfil y el usuario en un solo lugar. La descripción de Salesforce: “comprueba la configuración de la organización, del perfil y del usuario actual y devuelve el valor más específico, o de nivel más bajo” (Define Custom Settings (se abre en una pestaña nueva), Salesforce Help, consultado el 2026-10-27). Desactívala para la organización, actívala para el usuario de migración, y el usuario de migración obtiene el bypass mientras todos los demás tienen la automatización normal. Para la mayor parte del resto de la configuración, Salesforce te orienta ahora hacia los metadatos personalizados, que se implementan con tu código; yo los usaría para los interruptores por automatización.

En Apex, la comprobación es lo primero que hace el desencadenador. Así podría ser en la orden de trabajo, con una configuración personalizada de jerarquía llamada Automation_Bypass__c y un permiso personalizado llamado Bypass_Automation:

trigger WorkOrderTrigger on WorkOrder (after insert, after update) {
    // The hierarchy custom setting: the user's value, else the profile's, else the org's
    Automation_Bypass__c settings = Automation_Bypass__c.getInstance();

    // Bypass if the setting says so, or if this user holds the custom permission
    Boolean bypass = settings.Disable_Triggers__c == true
        || FeatureManagement.checkPermission('Bypass_Automation');

    if (bypass) {
        return;   // no side effects; the record still saves
    }

    WorkOrderStatusOut.publish(Trigger.new, Trigger.oldMap);
}

getInstance() returns the setting “for the current user,” merged from the lowest level that’s defined (Custom Settings Methods (se abre en una pestaña nueva)), and FeatureManagement.checkPermission “checks whether a custom permission is enabled” (FeatureManagement Class (se abre en una pestaña nueva); both Apex Reference Guide, Winter ‘27, checked 2026-10-27). ⟲

Y un interruptor por automatización, para que el bypass tenga un alcance delimitado en lugar de “saltarse todo”. Un tipo de metadatos personalizados, Automation_Switch__mdt, con un registro por automatización:

public with sharing class WorkOrderStatusOut {
    public static void publish(List<WorkOrder> orders, Map<Id, WorkOrder> oldOrders) {
        // One record per automation; switched off here, it's off everywhere it's deployed
        Automation_Switch__mdt sw = Automation_Switch__mdt.getInstance('WorkOrder_Status_Out');
        if (sw != null && sw.Is_Off__c) {
            return;
        }
        // ... publish the status change for the partners
    }
}

getInstance(developerName) reads one custom metadata record by its name (Custom Metadata Type Methods (se abre en una pestaña nueva), Apex Reference Guide, checked 2026-10-27). ⟲

En un flujo, es la misma idea: el primer elemento es una decisión.

Clic para ampliar

La comprobación va primero. Activada, el flujo se aparta.

La condición de la decisión lee los mismos dos interruptores, mediante las variables globales de Flow: $Permission es “el acceso a permisos personalizados del usuario que ejecuta el flujo”, y $Setup lee las configuraciones personalizadas de jerarquía (Global Variables Resource (se abre en una pestaña nueva), Salesforce Help, consultado el 2026-10-27). Como recurso de fórmula:

{!$Permission.Bypass_Automation} || {!$Setup.Automation_Bypass__c.Disable_Flows__c}

En una regla de validación, el bypass es una condición más. Esta es la regla de instalación de R12, con el usuario de migración autorizado a pasar (los nombres de campo son ejemplos):

AND(
  NOT($Permission.Bypass_Automation),
  ISPICKVAL(Status, "Completed"),
  Install_Required__c,
  NOT(Install_Checklist_Complete__c)
)

Las reglas de validación hacen referencia a un permiso personalizado como $Permission.Custom_Permission_Name (Cómo hacer referencia a un conjunto de permisos en una fórmula / regla de flujo de trabajo / regla de validación (se abre en una pestaña nueva), Salesforce Help, consultado el 2026-10-27).

La guía de decisión de Salesforce llama a los permisos personalizados “el estándar moderno y escalable para implementar la lógica de bypass”, y señala que un bypass se puede conceder a un solo usuario, “o incluso de forma temporal con una fecha y hora de caducidad concretas” (Record-Triggered Automation (se abre en una pestaña nueva), consultado el 2026-10-27). Esa es la ventana de la migración, incorporada a la concesión.

Son ejemplos que adaptar, no un marco que pegar: construye el tuyo, pruébalo en un sandbox y prueba que el interruptor vuelve a desactivarse. Y recuerda lo que has construido. Un bypass es un permiso para saltarse reglas de negocio. Concédesela al usuario de migración durante la ventana de la migración, registra quién la tiene y quítasela cuando termine la carga (el módulo 4 lo incluye en el runbook).

Conocimiento para el examen. Conoce los tres lugares donde guardar un bypass y a quién se aplica cada uno: un permiso personalizado (solo a los usuarios cuyos conjuntos de permisos lo conceden; se comprueba con $Permission en los flujos y las reglas de validación, y con FeatureManagement.checkPermission en Apex), una configuración personalizada de jerarquía (la organización, un perfil o un usuario, y gana el valor más específico; $Setup en los flujos y las fórmulas, getInstance() en Apex) y los metadatos personalizados (un interruptor por automatización, implementable).

Un bypass no es “sáltatelo todo”

Un bypass no significa que el usuario de migración ignore todas las reglas de Salesforce. Una automatización debe saltarse y otra debe seguir ejecutándose; una regla de validación que protege una invariante fundamental sigue importando, una notificación no; hay que suprimir una integración posterior, y una relación obligatoria sigue necesitando comprobación. Así que quiero bypasses intencionados y acotados, no Migration_Mode__c = true y, por tanto, nada importa. El camino de la migración sigue teniendo reglas, solo las que son apropiadas para la migración.

Y el bypass debería representar un contexto operativo, no un accidente. Una identidad de migración dedicada (módulo 2), un permiso personalizado, metadatos de configuración, una marca de función o una combinación de ellos pueden reconocer el trabajo de migración aprobado. La identidad puede formar parte del control, pero no quiero cada automatización codificada a fuego con User.Name = 'Migration User'. Eso es frágil. Expresa la intención: si esta es una operación de migración aprobada, sáltate este efecto secundario.

Las reglas de validación necesitan criterio

“La fecha de cierre es obligatoria cuando una oportunidad está Closed Won” es una invariante real de los datos; mantenla para las oportunidades históricas. Una regla que obliga a rellenar un campo del proceso actual introducido hace tres años es distinta: los registros de hace diez años nunca lo tuvieron, e inventar un valor empeora los datos. La pregunta no es “¿desactivamos las reglas de validación?”. Es ¿qué reglas representan una verdad duradera de los datos, y cuáles representan el proceso interactivo de hoy? Esa es una pregunta de arquitecto de datos.

Steve Trucking tiene una de cada. Cada orden de trabajo debe tener un socio minorista: es una verdad duradera, y se mantiene activa en la carga; una entrega de RouteDesk sin socio va a cuarentena (módulo 1). Pero el requisito R12 dice que una instalación no se puede cerrar sin una lista de comprobación completada y fotos concretas: la toma de agua, el desagüe, la nivelación. Ese es el proceso de hoy, construido para los equipos con la nueva aplicación móvil. Las instalaciones completadas de RouteDesk nunca tuvieron esas fotos. Desactiva esa regla para el usuario de migración y cárgalas como completadas. No te inventes las fotos.

La señal de alarma a vigilar: el destino exige un valor, el origen no lo tiene, así que “pon ‘Desconocido’ en todo”. Si Desconocido es un valor aprobado que describe de verdad el estado, bien. Si estamos insertando valores falsos para pasar la validación, estamos corrompiendo los datos para contentar a la aplicación. Prefiero diseñar una excepción de migración, un campo histórico que admita nulos, una regla de transformación o un valor de estado heredado antes que fingir que sabemos algo que no sabemos.

La automatización multiplica el Número de Ceros

Carga 2 millones de cuentas; la automatización crea 2 tareas por cada una: 4 millones de tareas. ¿Intencionado, o un accidente? Luego cada tarea dispara otro flow, la automatización de la cuenta actualiza un padre, publica un evento, recalcula otra cosa. El rendimiento de la migración no es lo rápido que la Bulk API inserta cuentas. La carga de trabajo real es el grafo de transacciones que crean esas inserciones. El Número de Ceros se multiplica a través de la automatización.

Ahora acércate a las tres flechas rojas de RouteDesk y cuenta.

Clic para ampliar

Cada registro, multiplicado por todo lo que desencadena.

El capítulo 9 activó Change Data Capture para las órdenes de trabajo, así que el suscriptor de Snowflake recibe un evento de cambio por cada creación. Son unos 196.400 eventos en un fin de semana, y sin un complemento la asignación diaria de eventos entregados es de 50.000 en las ediciones Performance y Unlimited, contada por suscriptor (Change Data Capture Allocations (se abre en una pestaña nueva), consultado el 2026-10-27). Los socios recibirían mensajes de estado de unas 190.000 entregas que cerraron hace semanas. El ERP de finanzas contaría entregas que ya ha facturado, y a los socios se les facturaría dos veces. Y los destinatarios recibirían mensajes sobre entregas que ya ocurrieron.

Clic para ampliar

Conserva solo los resultados que necesitas: una carga de recuperación, mensajes de las entregas abiertas, nada a los socios ni a finanzas.

Los efectos secundarios externos son peores. Correos a clientes, solicitudes de facturación, eventos que consumen sistemas de producción, llamadas al ERP, tickets de soporte, actualizaciones de marketing: esos sistemas no saben que son datos de migración, y una vez que el mensaje sale de Salesforce, deshacerlo puede ser imposible. El capítulo 9 nos dio el contrato de datos de la integración; durante la planificación de la migración, decide cuáles de esas flechas pueden funcionar, cuáles se suprimen y cuáles se sustituyen por una sincronización después del corte. Esa decisión va en el plan de corte.

Datos derivados, uso compartido y el objeto de staging

Resúmenes acumulativos y otros valores derivados: ¿cargar un padre, luego millones de hijos, y recalcular después de cada hijo? Quizá. A menudo es mucho más barato cargarlo todo y calcular una sola vez. La pregunta es si el resultado derivado debe mantenerse registro a registro durante la migración, o puede establecerse cuando los datos dependientes estén completos. Es la misma decisión de no la necesites / simúlala / aplázala.

El uso compartido también son datos derivados. Crear y transferir registros dispara el cálculo de las reglas de uso compartido, y en una carga grande eso puede suponer evaluaciones muy largas o tiempos de espera agotados. Salesforce permite a un administrador aplazar los cálculos de uso compartido (las reglas de uso compartido y la pertenencia a grupos) y reanudarlos después, pero la función no está activada por defecto: la activa el Soporte de Salesforce. Al reanudar, debes ejecutar un recálculo completo, y algunos cambios de uso compartido se siguen calculando de inmediato para proteger la integridad de los datos (Defer Sharing Calculations (se abre en una pestaña nueva)). Planifícalo, y planifica el tiempo del recálculo.

Deferring has limits of its own. The catch-up usually runs as batch Apex, and that shares the org’s daily allowance of asynchronous Apex executions: “250,000 or the number of applicable user licenses in your org multiplied by 200, whichever is greater.” Only five batch jobs can be queued or active at once, with up to 100 more waiting in the flex queue (Execution Governors and Limits (se abre en una pestaña nueva), Apex Developer Guide, Winter ‘27, checked 2026-10-27). Your catch-up competes with every other batch job in the org, so schedule it, and size it. ⟲

Conocimiento para el examen. Las cargas grandes desencadenan el recálculo del uso compartido. El soporte de Salesforce puede habilitar los cálculos de uso compartido diferidos (reglas de uso compartido y pertenencia a grupos), que reanudas y recalculas después de la carga. El trabajo aplazado suele ejecutarse como Apex por lotes, dentro del límite diario de Apex asíncrono y de cinco trabajos por lotes simultáneos.

Y a veces la lógica que necesitas es sencillamente demasiado lenta para cargar a través de ella. Este es el caso especial que mencionaba el módulo 1. Un proceso que tarda uno o dos segundos por registro está bien para los usuarios; para cientos de miles de registros en una ventana de corte significa días, e intentar simular un modelo de objetos intrincado en la carga puede suponer una docena de tablas. La técnica que uso: cargar primero en un objeto de staging, un objeto personalizado ligero sin automatización que guarda los campos de importación y las búsquedas, y luego dejar que un proceso por lotes lo recorra, llamando a la propia lógica de la plataforma para construir los registros reales. El estado de cada fila de preparación permite al lote trabajar por bloques, pausarse y reanudarse, y los campos de importación originales se quedan junto a los registros que crearon, para poder rastrearlos. Metes los datos rápido y te pones al día con el procesamiento después.

Diseña para el estado final, y déjalo por escrito

El objetivo no es “ejecutar la automatización de producción”. Es llegar al estado de producción correcto, y no son lo mismo. El procesamiento normal de una cuenta nueva deriva una clasificación, crea una tarea de bienvenida, envía una notificación y publica en otro sistema. Para una cuenta histórica migrada, el estado final correcto puede ser: clasificación sí, tarea de bienvenida no, notificación de bienvenida no, publicación externa quizá, según el plan de sincronización. Ejecutar a ciegas la automatización normal reproduce un proceso que no se diseñó para la migración.

Para una migración seria, déjalo por escrito como un inventario de automatizaciones:

Automatización	Comportamiento normal	Decisión de migración	Resultado de migración necesario
Estado hacia los socios	Enviar cada cambio de estado a Redrock, Keystone, Brightwave	No se necesita	Ninguno: los socios ya lo tienen
Change Data Capture hacia Snowflake	Un evento de cambio por orden de trabajo	Aplazar	Una carga de recuperación del historial de estados después de la carga
Recuentos de entregas hacia finanzas	Contar cada entrega completada para facturar	No se necesita	Ninguno: ya facturado; en su lugar, conciliar el recuento
Mensaje del día anterior	Enviar al destinatario un enlace de seguimiento	Ejecutar de forma deliberada, solo entregas abiertas	Los destinatarios del lunes reciben el enlace; ninguno para las entregadas
Estado de la orden de trabajo	Lo fija la aplicación de los equipos	Simular	Estado convertido en el almacén de datos de preparación
Lista de comprobación y fotos de instalación (R12)	Impedir cerrar una instalación sin ellas	Bypass para el usuario de migración	Las instalaciones completadas se cargan como completadas; sin fotos inventadas
Cada orden de trabajo tiene un socio	Rechazar una orden de trabajo sin socio	Mantener	Socio que falta: a cuarentena antes de la carga

Ahora la decisión es visible: podemos revisarla, probarla, ensayarla y verificarla después de la carga.

Ensaya el bypass y luego vuelve a activarlo todo

No hagas que producción sea la primera vez que usas el modo de migración. El ensayo debería probar la identidad de migración, los controles de bypass, las automatizaciones que siguen activas, los resultados simulados, los procesos aplazados y la vuelta al modo normal, y luego comprobar: ¿se disparó algo que no debía?, ¿dejó de ocurrir algo que debía?, ¿coincide el estado final con la arquitectura? Por eso el ensayo necesita la configuración real de la automatización, o algo tan parecido como sea práctico.

Volver a activar es un paso del corte: explícito, con un responsable con nombre, una hora prevista y verificación. No “acuérdate de volver a activar los flows”. El sistema no está listo para los usuarios hasta que el funcionamiento normal se restablece y se verifica (el módulo 4 lo pone en el runbook).

Y cuidado con la avalancha de puesta al día. Suprimimos la sincronización con los sistemas posteriores mientras cargábamos los registros de RouteDesk; ahora volvemos a activar la integración. ¿Ve cinco millones de registros “nuevos” e intenta enviarlos todos? Quizá el sistema posterior ya los recibió por otra vía, quizá solo deberían ir los cambios posteriores a la marca de agua del corte, quizá necesite una sincronización inicial controlada. La decisión sobre la automatización y la decisión sobre la integración tienen que ir de la mano. Volver a activar la automatización no basta: sabe qué hará cuando despierte. Para Steve Trucking, los flujos de estado y el suscriptor de Change Data Capture deberían ver solo los cambios hechos después del corte, nunca la carga del fin de semana.

La IA hace más importante el diseño del bypass

Ahora añade agentes que reaccionan a un caso nuevo, una cuenta modificada, un evento publicado o una tarea en una cola. Una migración crea patrones de datos a escala de máquina; ¿queremos que los agentes reaccionen a cada registro migrado? Probablemente no por accidente. Los procesos que disparan los agentes pertenecen al mismo inventario que los flows, los triggers, las notificaciones, las integraciones y los eventos, y si el contexto de migración debe suprimirlos, diséñalo a propósito.

Más allá del examen: lo que cambia la IA. Los agentes son otro tipo de efecto secundario, uno que puede reaccionar de forma autónoma a los datos migrados. Trata las acciones que disparan los agentes como cualquier otra automatización: decide si se ejecutan, se simulan, se aplazan o se suprimen, y prueba la decisión en el ensayo.

Lo que decide aquí un arquitecto

• Qué automatizaciones se ejecutan, no se necesitan, se simulan o se aplazan para cada clase de datos migrados, sabiendo que desactivar una significa asumir su lógica de negocio.
• Qué reglas de validación representan una verdad duradera de los datos, y cuáles son reglas del proceso actual que necesitan un tratamiento específico para la migración.
• Cómo se diseñan desde el principio bypasses con un alcance delimitado en cada automatización, probados activados y desactivados e implementados mucho antes de que hagan falta, sin un camino ilimitado de “saltarse todo”.
• Cómo se gestionan los datos derivados, el recálculo del uso compartido y la lógica lenta de la plataforma: después de la carga, aplazados o mediante un objeto de staging.
• Qué efectos secundarios externos e integraciones se suprimen o se ponen al día a propósito, y cómo el ensayo y el corte demuestran que la automatización normal se restableció con seguridad.

Haz que sea una decisión

La migración no tiene éxito porque se ejecutara cada flow, se disparara cada trigger y se ejecutara cada regla de validación. Ese es el comportamiento normal de las transacciones, y la migración tiene otro trabajo: llevar los datos a la nueva arquitectura, preservar las verdades que importan, crear los valores derivados que necesitamos, evitar efectos secundarios falsos, mantener el sistema bajo control y luego devolverlo a la normalidad. Para cada automatización: no la necesites, simúlala, aplázala, o déjala ejecutarse a propósito. Pero haz que sea una decisión. No dejes que la tomen cinco millones de registros por ti.

Explora

• Salesforce Help, Defer Sharing Calculations (se abre en una pestaña nueva) and Retirada de Reglas de flujo de trabajo y Process Builder (se abre en una pestaña nueva), checked 2026-11-01. ⟲
• Salesforce Help, Define Custom Settings (se abre en una pestaña nueva), Global Variables Resource (se abre en una pestaña nueva) (Flow) and Cómo hacer referencia a un conjunto de permisos en una fórmula / regla de flujo de trabajo / regla de validación (se abre en una pestaña nueva); Apex Reference Guide, FeatureManagement Class (se abre en una pestaña nueva), Custom Settings Methods (se abre en una pestaña nueva) and Custom Metadata Type Methods (se abre en una pestaña nueva), Winter ‘27; all checked 2026-11-01. ⟲
• Salesforce Architects, decision guide, Record-Triggered Automation (se abre en una pestaña nueva) (“Bypassing Automation”), checked 2026-11-01. ⟲
• Salesforce Architects, Well-Architected, Automation Patterns (se abre en una pestaña nueva) and Resource and Cost Optimization (se abre en una pestaña nueva), checked 2026-11-01. ⟲
• Salesforce, Apex Developer Guide, Execution Governors and Limits (se abre en una pestaña nueva), Winter ‘27 (API version 68.0), and Change Data Capture Developer Guide, Change Data Capture Allocations (se abre en una pestaña nueva), checked 2026-11-01. ⟲
• En este curso: Integración y movimiento de datos (el contrato de datos de la integración) y Diseñar para la escala.