# architect Guías de decisiones (decision-guides) - Full Documentation

<!-- document id=7752c37425c5d5936a5950e57ccb2f88f0ba7e51b384eb0f8a513d70c40641be url=/architect/next/es-mx/decision-guides/guides/data-360-provisioning.md -->

## Descripción general

Salesforce Data 360 es una plataforma de datos creada sobre <a href="https://www.salesforce.com/platform/public-cloud-infrastructure/">Hyperforce</a> que unifica datos externos y de Salesforce en una visión clara, completa y de confianza de 360 grados de cada cliente o cuenta.

Las compañías a menudo operan múltiples organizaciones de Salesforce debido a fusiones y adquisiciones, operaciones regionales, separación funcional o por motivos históricos. Los arquitectos deben decidir no solo entre una única organización de inicio frente a una configuración de múltiples organizaciones, sino también si aprovisionar múltiples instancias de Data 360 independientes, utilizar Data Cloud One para unificar organizaciones bajo una única instancia o colaborar entre instancias de Data 360 independientes utilizando la colaboración de datos entre Data 360 (colaboración de datos de Data 360 a Data 360). Estas opciones afectan a la gobernanza, el cumplimiento, el costo, la latencia y la capacidad de la organización para ampliar la IA y las funciones de plataforma entre organizaciones.

Data 360 se aprovisiona automáticamente en cualquier organización de producción que recibe una licencia de Data 360. Data Cloud One es la arquitectura de conectividad de múltiples organizaciones de Salesforce que permite a una única organización de inicio alojar la instancia de Data 360, mientras que otras organizaciones de Salesforce se conectan como organizaciones complementarias. La elección de qué organización posee la licencia Data 360 y, por lo tanto, se convierte en una organización de inicio de Data 360, es una decisión arquitectónica crítica con consecuencias a largo plazo.

El modo de aprovisionar Salesforce Data 360 es una decisión arquitectónica fundamental porque determina cómo la compañía unifica los datos de los clientes, aplica la gobernanza y activa funciones críticas de la plataforma, especialmente IA, Agentforce y análisis, en toda la organización. Anclar un clúster de organizaciones a un único Data 360 proporciona un modelo de datos unificado, una gobernanza centralizada y preparación para la IA de toda la compañía, mientras permite a las organizaciones de compañía acceder a funciones y metadatos compartidos como si los datos fueran locales. Por el contrario, múltiples instancias independientes de Data 360 son apropiadas cuando los requisitos de regulación, cumplimiento o autonomía impiden la centralización, con Colaboración de datos entre organizaciones de Data 360 activando la colaboración selectiva sin copia entre estas instancias.

Para los arquitectos, esta decisión es crítica. Define quién controla la gobernanza de los datos, dónde residen los datos, cómo se activan las funciones de plataforma y con qué facilidad se pueden ampliar futuras integraciones e iniciativas de IA. Incluso para organizaciones que no tienen Data 360 en estos momentos, puede ser importante preparar su arquitectura para el futuro desarrollando una estrategia para agregar acceso a Data 360 en adelante. Las funciones de Salesforce en Sales, Service, Marketing, Commerce, Industries y Agentforce se crean cada vez más en Data 360. Las organizaciones que desean utilizar estas funciones de plataforma deben aprovisionar sus propios Data 360 o conectarse a un Data 360 compartido como organizaciones complementarias.

Esta guía ayuda a los arquitectos a diseñar una estrategia de aprovisionamiento que equilibra la sencillez, la coherencia de toda la compañía, el cumplimiento y la escalabilidad, garantizando que la organización puede aprovechar Data 360 con confianza para Customer 360, la IA y la innovación entre plataformas. Le ayudará a decidir cómo seleccionar en qué organizaciones aprovisiona Data 360 y cómo elegir entre Data Cloud One y Colaboración de datos entre organizaciones de Data 360, ayudando a sentar las bases firmes que mueven su negocio hacia un futuro centrado en Data 360.

---

## Consideraciones sobre el aprovisionamiento

Cada opción de aprovisionamiento, ya sea elegir entre Data Cloud One y la colaboración de datos entre organizaciones de Data 360, o qué organización designar como la organización de inicio, debe evaluarse teniendo en cuenta estas consideraciones transversales:

<table>
<tr>
<th>Consideración</th>
<th>Por qué importa</th>
<th>Escenarios de ejemplo</th>
</tr>
<tr>
<td><strong>Residencia y cumplimiento de datos</strong></td>
<td>Determina dónde se almacenan y procesan los datos. Las reglas reguladoras pueden requerir regiones específicas o múltiples instancias.</td>
<td>Un banco global aprovisiona un arrendatario de Data 360 en una organización de Salesforce geolocalizada en Frankfurt para el cumplimiento del RGPD y otro en una organización en Virginia para su división de EE.UU.</td>
</tr>
<tr>
<td><strong>Gobernanza y seguridad</strong></td>
<td>¿Quién es el propietario y el administrador de Data 360? ¿Deben gestionarse las políticas de forma centralizada o delegarse por unidad de negocio?</td>
<td>Una multinacional con una sólida TI central crea una organización doméstica dedicada gestionada por un Centro de excelencia.</td>
</tr>
<tr>
<td><strong>Autonomía vs. Centralización</strong></td>
<td>Es posible que diferentes líderes deseen la propiedad separada de los datos. La autonomía favorece múltiples Data 360; la centralización favorece Data Cloud One .</td>
<td>Un holding con filiales independientes permite a cada unidad de negocio ejecutar su propio Data 360.</td>
</tr>
<tr>
<td><strong>Latencia y desempeño</strong></td>
<td>Afecta a la velocidad y la experiencia de las consultas, especialmente para organizaciones de compañía conectadas a un arrendatario de Data 360 entre regiones.</td>
<td>Un equipo de ventas en Londres que consulta datos de un arrendatario de Data 360 en EE.UU. puede ver una latencia más alta.</td>
</tr>
<tr>
<td><strong>Complejidad de integración</strong></td>
<td>Más arrendatarios de Data 360 = más oportunidades en curso, API y middleware. La consolidación simplifica la integración.</td>
<td>Un minorista evita crear 10 oportunidades en curso de ETL consolidándolas en una configuración de Data Cloud One.</td>
</tr>
<tr>
<td><strong>Región de origen de datos de copia cero</strong></td>
<td>Los conectores de copia cero pueden tener requisitos de acceso entre regiones que limitan en qué regiones se puede ubicar su Data 360.</td>
<td>Una compañía tiene una instancia de Snowflake en la región eu-west-1 de AWS. Pueden utilizar Cero copia para federar datos a Data 360 en su región, pero no pueden utilizar Cero copia para federar a Data 360 en la región de EE.UU.</td>
</tr>
<tr>
<td><strong>Compatibilidad entre regiones de Connect privada</strong></td>
<td>En algunos casos, la compatibilidad de Conexión privada depende de si el origen de datos está en la misma región que el arrendatario de Data 360.</td>
<td>Una compañía tiene una instancia de Snowflake en la región aws-east-1 a la que desea conectarse a través de copia cero. Solo pueden establecer una conexión de red de Conexión privada si la organización de inicio de Data 360 está en la misma región.</td>
</tr>
<tr>
<td><strong>Costo y licencias</strong></td>
<td>Cada arrendatario de Data 360 agrega costo. La consolidación en menos instancias optimiza el gasto.</td>
<td>Un proveedor de cuidados sanitarios reduce los costos de licencias adoptando Data Cloud One en vez de múltiples instancias independientes de Data 360.</td>
</tr>
<tr>
<td><strong>Escalabilidad futura</strong></td>
<td>Las opciones de aprovisionamiento establecen hoy las bases para el crecimiento.</td>
<td>Una compañía de SaaS comienza con una única instancia de Data 360 pero planea ampliar a Data Cloud One a medida que adquiere filiales con organizaciones de Salesforce.</td>
</tr>
<tr>
<td><strong>Preparación de IA de toda la compañía</strong></td>
<td>Las funciones de IA y Agentforce requieren un arrendatario de Data 360 conectado en cada organización. Las decisiones de aprovisionamiento afectan al modo en que los modelos de IA se entrenan y activan en toda la compañía.</td>
<td>Una compañía de servicios financieros unifica datos en Data Cloud One de modo que sus modelos de IA de Einstein tengan acceso a datos de clientes de toda la compañía.</td>
</tr>
</table>

### Consideraciones importantes

<ul>
<li>El <strong>aprovisionamiento está vinculado a licencias</strong>: Data 360 se aprovisiona en la organización donde se adquiere la licencia Data 360, y la región se determina por la ubicación de esa organización en el momento del aprovisionamiento.</li>

<li><strong>Mantenga sus opciones abiertas planificando Data 360</strong> incluso si no las necesita ahora. Las decisiones que tome ahora pueden suavizar su camino si implementa Data 360 para impulsar funciones de plataforma como Agentforce más adelante.</li>

<li><strong>Clientes de una sola organización</strong>: Aprovisione Data 360 en su organización de producción existente para un tiempo de valor más rápido.</li>

<li><strong>Clientes de múltiples organizaciones</strong>: Minimice la complejidad creando el menor número posible de instancias de Data 360, idealmente utilizando la configuración de Data Cloud One.</li>

<li><strong>Múltiples instancias Data 360</strong> solo deben utilizarse cuando lo requiera el cumplimiento, la residencia o la autonomía organizativa. En esos casos, utilice la colaboración de datos entre organizaciones de Data 360 para activar la colaboración segura.</li>

<li><strong>Orígenes de datos</strong> de copia cero: Preste mucha atención a qué regiones son compatibles con varias nubes públicas y orígenes de datos de copia cero. Del mismo modo, determine si se requiere Conexión privada para su postura de seguridad para conectar con esos orígenes de datos y si se admiten conexiones en región o entre regiones.</li>

<li><strong>Gobierno y autonomía</strong> son conceptos centrales: decida si Data 360 debe gestionarse de forma centralizada (modelo Centro de excelencia) o si las líneas de negocio individuales necesitan instancias de Data 360 gestionadas de forma separada.</li>
</ul>

---

## Sección 1: Aprovisionamiento de Data 360: Selección de la organización de inicio

### 1.1 ¿Qué es una organización de inicio de Data 360?

Cuando adquiere una licencia de Data 360, la instancia de Data 360 se aprovisiona en la organización de Salesforce asociada con esa licencia. Esta organización se denomina Organización de inicio de Data 360.
<img style="border:1px solid #e5e5e5;float:right;width:35%;margin:1rem 2rem 1rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data 360 Home Org.png" alt="Diagrama de decisiones mostrando la organización de inicio de Data 360" />
La organización de inicio es el anclaje para su instancia de Data 360. Es donde:

- El almacenamiento y la computación de Data 360 están gestionados (en la región seleccionada en el aprovisionamiento).
- Se aplican políticas de administración, gobernanza y seguridad.
- Se realiza el ingreso, Armonización, Resolución de identidad, Segmentación y Activación de datos.

En escenarios de múltiples organizaciones, la organización de inicio gestiona la instancia central de Data 360 para otras organizaciones "compañeras" de Salesforce.

Por qué importa la organización de inicio:

- Determina la ubicación geográfica de su instancia de Data 360.
- Determina quién es el propietario y el administrador de su instancia de Data 360. Los administradores de su organización de inicio de Data 360 pueden acceder a todos los datos ingresados en Data 360.
- Controla las conexiones de la organización de compañía en una configuración de Data Cloud One.
- Establece las bases para su estrategia de datos de compañía: cambiarla más adelante es difícil e interrumpe.

### 1.2 Decisión: ¿Organización existente o Nueva organización como la organización de inicio?

La primera decisión importante es si aprovisionar Data 360 en una organización de producción existente o crear una nueva organización dedicada para actuar como la organización de inicio.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data 360 Existing_Org_vs_New_Dedicated_Org.png" alt="Diagrama de decisiones mostrando la organización existente frente a la nueva organización como organización de inicio" />

#### Opción A: Aprovisionar datos 360 en una organización existente

**Funciona mejor para:** Clientes con una única organización de Salesforce o clientes de múltiples organizaciones que ya tienen una organización centralizada principal donde se ejecuta la mayoría de los negocios.

<img style="border:1px solid #e5e5e5;float:right;width:45%;margin:1rem 2rem 1rem 0rem"  src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data360 DC_Home_as_an_existing.png" alt="Gráfico que muestra el aprovisionamiento de Data 360 en una organización existente" />

- **Pros**:

  - Ruta más sencilla: Data 360 se aprovisiona donde ya se encuentran sus datos de CRM.
  - Acceso inmediato a datos locales de Ventas, Servicio y Marketing.
  - No se requiere integración adicional.
  - Menos licencias y entornos para gestionar.
  - Acelera la adopción temprana, los pilotos y los casos de uso de producción.

- **Cons**:
  - Puede heredar la deuda técnica o de gobernanza de la organización existente.
  - Si no existe ninguna “organización principal” única, la selección de una puede crear debates sobre la propiedad.
  - Desempeño vinculado a la ubicación de la organización; puede no estar en sintonía con las necesidades de residencia de toda la compañía.
  - Si varias unidades de negocio utilizan organizaciones diferentes, el aprovisionamiento local puede llevar a la fragmentación si no se empareja con Data Cloud One.

**Ejemplo:**  
Una compañía SaaS con una organización de Salesforce aprovisiona Data 360 en esa organización para unificar los datos de asistencia y suscripción de clientes.

#### Opción B: Aprovisionar Data 360 en una organización nueva y exclusiva

**Funciona mejor para:** Clientes con múltiples organizaciones de Salesforce que no pueden alinearse en una única organización principal, o empresas con un modelo de Centro de excelencia (CoE) sólido.

<img style="border:1px solid #e5e5e5;float:right;width:45%;margin:1rem 2rem 1rem 0rem"  src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data360 DC_Home_as_new_dedicated_org.png" alt="Gráfico que muestra el aprovisionamiento de Data 360 en una nueva organización dedicada" />

- **Pros**:

  - Borrón y cuenta nueva para la gobernanza, sin complejidades de organización heredadas.
  - Control centralizado entre múltiples líneas de negocio.
  - Flexibilidad para elegir una región basándose en necesidades de cumplimiento.
  - Actúa como una organización de “servicio compartido” neutral, no vinculada a una unidad de negocio.
  - Configure la futura arquitectura de Data Cloud One (Organización de inicio con múltiples organizaciones de compañía).

- **Cons**:
  - Los clientes deben otorgar licencias a una nueva organización de Salesforce para aprovisionar Data 360.
  - Integración adicional requerida para conectar la organización con Data 360 a través de una conexión complementaria de Data Cloud One.
  - Puede agregar gastos administrativos (gestión de usuarios, seguridad, identidad).
  - Tiempo de valor más lento en comparación con el aprovisionamiento en una organización de producción existente.

**Ejemplo:**  
Una compañía multinacional de servicios financieros crea una organización de inicio exclusiva para aprovisionar Data 360. Todas las organizaciones de unidades de negocio (Retail, Wealth, Commercial Banking) se conectan como organizaciones complementarias a través de Data Cloud One.

#### Criterios de decisión

<table>
<tr>
<th>Consideración</th>
<th>Organización existente como organización de inicio (Predeterminado preferido)</th>
<th>Nueva organización como organización de inicio (alternativa)</th>
</tr>
<tr>
<td><strong>Simplicidad</strong></td>
<td>Se basa en la estructura de datos y usuarios existentes para una configuración más rápida; Data 360 está integrado de forma predeterminada con la organización de inicio.</td>
<td>Requiere licencias y configuración de nueva organización de Salesforce, así como gastos administrativos adicionales para gestionarla.</td>
</tr>
<tr>
<td><strong>Tiempo hasta valor</strong></td>
<td>Uso inmediato de datos de CRM locales.</td>
<td>Rampa más lenta; se requiere integración.</td>
</tr>
<tr>
<td><strong>Gobernanza</strong></td>
<td>Hereda el modelo de gobernanza básico de la organización existente: usuarios y conjuntos de permisos existentes. Esto puede estar bien si la organización ya es central.</td>
<td>Borrón y cuenta nueva para la gobernanza; ideal para modelos dirigidos por centros de excelencia.</td>
</tr>
<tr>
<td><strong>Cumplimiento</strong></td>
<td>Residencia vinculada a la región de la organización existente.</td>
<td>Flexibilidad para seleccionar una región independiente de organizaciones existentes.</td>
</tr>
<tr>
<td><strong>Desempeño</strong></td>
<td>El mejor desempeño para consultas de CRM locales.</td>
<td>Dependiendo de la conectividad de la organización de compañía, ya sea en la misma región o entre regiones a las otras organizaciones.</td>
</tr>
<tr>
<td><strong>Escalabilidad futura</strong></td>
<td>Funciona bien si se empareja con Data Cloud One; es más difícil cambiar más adelante si se selecciona la organización incorrecta.</td>
<td>Se amplía fácilmente con Data Cloud One ; diseñado para la neutralidad.</td>
</tr>
<tr>
<td><strong>Costo</strong></td>
<td>Costo incremental inferior.</td>
<td>Mayor sobrecarga desde entornos adicionales.</td>
</tr>
</table>

### 1.3 Recomendaciones

Como principio general, favorezca el uso de una organización principal existente como su organización de inicio para minimizar el esfuerzo inicial y acelerar la adopción. Solo cree una organización de inicio nueva y exclusiva si su estrategia de cumplimiento o gobernanza a largo plazo lo requiere. La creación de una nueva organización de inicio exclusiva es una opción común para grandes empresas con un Centro de excelencia (COE).

**Entorno de organización única**

Aprovisione Data 360 en su organización de producción existente. Esto maximiza la simplicidad y el valor inmediato. Evita gastos generales de integración innecesarios.

**Entorno de múltiples organizaciones**

Prefiera seleccionar una de sus organizaciones principales (normalmente aquella donde se ejecuta la mayoría de su negocio o la organización que ya sirve como su CRM centralizado) para actuar como la organización de inicio. Esto reduce la complejidad, minimiza el trabajo de configuración y le permite obtener el valor de Data 360 rápidamente. El uso de una organización principal existente también evita el costo y el esfuerzo de integración de la gestión de un nuevo entorno.

**Cuándo considerar una organización de inicio nueva y exclusiva**

Si su organización tiene un Centro de excelencia (CoE) sólido y desea una gobernanza separada de las organizaciones de unidades de negocio. Si ninguna organización existente es adecuada debido al cumplimiento o las restricciones organizativas. En esos casos, la creación de una nueva organización de inicio proporciona flexibilidad y neutralidad, pero con un tiempo de valor más lento.

---

## Sección 2: Estrategia de múltiples organizaciones y Data Cloud One

### 2.1 El reto de múltiples organizaciones

Las compañías a menudo operan múltiples organizaciones de Salesforce, y este no es un caso de riesgo, sino la norma. En febrero de 2024, aproximadamente 19.000 clientes de Salesforce ya ejecutaban más de una organización de Salesforce.

¿Por qué sucede esto?

- **Adquisiciones y fusiones:** Las compañías recién adquiridas aportan sus propias instancias de Salesforce.
- **Operaciones regionales:** Organizaciones separadas para UE, Norteamérica, Asia-Pacífico, etc., a menudo para satisfacer leyes de residencia de datos.
- **Separación funcional:** Diferentes unidades de negocio (por ejemplo, Retail Banking, Wealth Management, Insurance) mantienen sus propias organizaciones para la autonomía.
- **Aislamiento normativo o de seguridad:** Algunas industrias exigen organizaciones lógicamente distintas por motivos de cumplimiento.
- **Motivos históricos/técnicos:** Con el tiempo, los clientes acumulan orgánicamente múltiples organizaciones.

Cada motivo tiene sentido individualmente, pero juntos crean fragmentación de datos. Sin una capa unificadora, cada organización solo tiene una vista parcial del cliente.

El reto arquitectónico: ¿Cómo unificar datos entre organizaciones en una única fuente de verdad respetando al mismo tiempo los requisitos de cumplimiento, gobernanza y autonomía?

---

### 2.2 ¿Qué es Data Cloud One?

Data Cloud One es la arquitectura de conectividad de múltiples organizaciones de Salesforce que permite a múltiples organizaciones de Salesforce compartir una única instancia de Data 360. Es el patrón recomendado para compañías con múltiples organizaciones de Salesforce.

En cualquier clúster de Data Cloud One, una organización de Salesforce se designa como la organización de inicio, que aloja la instancia de Data 360. Otras organizaciones de Salesforce se conectan como organizaciones complementarias, consumiendo los datos y metadatos unificados desde Data 360 de la organización de inicio.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies Data 360 DC One.png" alt="Gráfico que muestra la arquitectura de Data Cloud One" />

#### Cómo funciona Data Cloud One

<ol>
<li><strong>Ingreso y unificación de datos (Organización de inicio)</strong><br/>
   <ul>
   <li>Toda la configuración de ingreso de datos (Salesforce CRM, fuentes externas, transmisión, lote) se produce únicamente desde la Organización de inicio.</li>
   <li>El arrendatario de Data 360 vinculado a la Organización de inicio realiza la Resolución de identidad, Armonización, Modelado y Unificación en perfiles Customer 360 de confianza.</li>
   <li>La administración de Data 360, las políticas de gobernanza, el etiquetado y el enmascaramiento se aplican de forma centralizada desde la organización de inicio.</li>
   </ul>
</li>

<li><strong>Arquitectura de espacio de datos</strong><br/>
   <ul>
   <li>Desde la organización de inicio, los datos se organizan en Espacios de datos, que actúan como contenedores lógicos para datos, metadatos y procesos.</li>
   <li>Las compañías pueden crear Espacios de datos para marcas, regiones o líneas de negocio.</li>
   <li>Colaboración de espacio de datos: Desde la organización de inicio, los espacios de datos específicos se comparten de forma selectiva con organizaciones complementarias. Esto garantiza que solo los datos relevantes (y los metadatos asociados) fluyen a las organizaciones correctas.</li>
   </ul>
</li>

<li><strong>Compartir metadatos</strong><br/>
   Las organizaciones de compañía reciben definiciones de metadatos de la organización de inicio, incluyendo objetos de modelo de datos (DMO), esquema de perfil unificado, perspectivas calculadas, segmentos <a href="https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5">y mucho más</a>. Estos aparecen de forma nativa dentro de la organización complementaria como si fueran activos locales, pero en realidad están vinculados a la organización de inicio.</li>

<li><strong>Trabajos por hacer en organización de inicio frente a Organizaciones</strong> complementarias</li>  
   El acceso a funciones varía entre organizaciones de inicio y de compañía. Las organizaciones de compañía no pueden ingresar o unificar datos y dependen de la organización de inicio para el ingreso, el modelado y la unificación. Las organizaciones complementarias pueden acceder a datos de Data 360 para potenciar funciones de plataforma con tecnología de Data 360, y pueden crear perspectivas, segmentos y flujos locales sobre los datos compartidos de confianza. En una visión futura, también pueden acceder a funciones de activación.

<table>
<tr>
<th>Capacidad</th>
<th>Organización de inicio</th>
<th>Organización complementaria</th>
</tr>
<tr>
<td><strong>Conectar</strong> Configurar conectores, crear transmisiones de datos, ingresar o federar datos</td>
<td>✅</td>
<td>❌</td>
</tr>
<tr>
<td><strong>Armonizar y unificar</strong> Construir y ejecutar transformaciones de datos y resolución de identidad</td>
<td>✅</td>
<td>❌</td>
</tr>
<tr>
<td><strong>Gebernar</strong> datos seguros con espacio de datos y permisos</td>
<td>✅</td>
<td>✅</td>
</tr>
<tr>
<td>Construir segmentos, perspectivas y modelos de Einstein Studio <strong>para segmentar y predecir</strong></td>
<td>✅</td>
<td>✅</td>
</tr>
<tr>
<td>Activaciones de <strong>Activate Everywhere</strong>, acciones de datos</td>
<td>✅</td>
<td>✅</td>
</tr>
<tr>
<td><strong>Funciones de plataforma</strong> Generador de solicitudes, flujos, reportes, enriquecimiento <a href="https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5">y mucho más</a></td>
<td>✅</td>
<td>✅</td>
</tr>
<tr>
<td><strong>Funciones con tecnología</strong> de Data 360 Centro de prospección, funciones de Sales y Service Cloud, Agentforce y mucho más</td>
<td>✅</td>
<td>✅</td>
</tr>
</table>

<li><strong>Paridad de funciones de plataforma</strong><br/>
   	Desde la perspectiva de los usuarios y constructores, una vez compartidos los metadatos, existen algunas diferencias funcionales entre las organizaciones de inicio y de compañía en términos del uso de funciones de la plataforma Salesforce. La lista de funciones admitidas se puede encontrar en <a href="https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5">Funciones de Data 360 en organizaciones de compañía</a>.<br/>
   <ul>
   <li>Las funciones de la plataforma Salesforce, como Flujos, Reportes, Generador de solicitudes, tableros y otras herramientas nativas de la plataforma, funcionan en organizaciones de inicio y complementarias una vez que los metadatos están disponibles.</li>
   <li>Las funciones con tecnología de Data 360, como Agentforce, Centro de prospección, Sales Cloud Einstein y funciones de IA de Service Cloud, también funcionan a la perfección en organizaciones domésticas y de compañía. Algunas funciones pueden estar en su camino para alcanzar la compatibilidad completa, pero el objetivo general es tener paridad de funciones entre las organizaciones Inicio y Acompañante para todas las funciones entre nubes que dependen de Data 360.</li>
   </ul>
</li>

<li><strong>Modelo de consumo</strong><br/>
   Toda la actividad de la organización de compañía (consultas, ejecuciones de segmentos, flujos desencadenados por Data 360, uso de IA, registro de Capa Einstein Trust, etc.) consume créditos de Data 360 desde la organización de inicio. Flujos de consumo de una manera: los créditos se centralizan, se facturan y se realizan un seguimiento en la asignación de crédito de la organización de origen. Sin embargo, puede desglosar para ver cuántos créditos utilizó cada organización individual en Digital Wallet.</li>

<li><strong>Principio de diseño: Construcción horizontal</strong><br/>
   Data Cloud One está diseñado como una construcción horizontal de la plataforma Salesforce, muy parecida a Sandboxes. El objetivo es que cada nueva función que Salesforce publique funcione en organizaciones de inicio y de compañía sin configuración adicional. Esto garantiza que Data Cloud One no sea solo una opción de arquitectura de datos, sino un elemento fundamental de Salesforce Platform en adelante.</li>
</ol>

---

### 2.3 Decisión: Múltiples 360 de datos independientes frente a One Shared Data 360 (Data Cloud One)

Las compañías con múltiples organizaciones deben elegir cómo y dónde localizar Data 360 en su ecosistema. ¿Desea aprovisionar Data 360 independientes en cada organización o utilizar Data Cloud One para unificar organizaciones bajo una única organización de inicio?

#### Opción A: Múltiples 360 de datos independientes

Cada organización de Salesforce aprovisiona su propia instancia de Data 360.

**Pros**:

- **Autonomía**: Cada unidad de negocio o región controla su propio Data 360.
- **Simplicidad** en cada organización: La gobernanza, la seguridad y las personalizaciones están traducidas.
- **Cumplimiento normativo**: Útil cuando se requiere una separación regulatoria estricta (por ejemplo, los datos no deben cruzar fronteras).

**Cons**:

- **Silos de datos:** Customer 360 no se puede alcanzar entre organizaciones.
- **Mayor costo**: Cada instancia requiere licencias, administración e integración. Los clientes terminan ingresando los mismos datos de origen varias veces para obtener una vista completa de C360 en múltiples organizaciones diferentes.
- **Trabajo duplicado:** La resolución de identidad, la segmentación y el enriquecimiento deben repetirse en cada Data 360.

#### Opción B: One Shared Data 360 (Clúster de Data Cloud One)

Se proporciona un único Data 360 en una organización de inicio, con otras organizaciones de Salesforce conectadas como organizaciones complementarias.

**Pros**:

- **Fuente de verdad única (SSOT):** Todas las organizaciones comparten el mismo modelo de datos unificado.
- **Eficiencia de costos:** Solo una licencia e infraestructura de Data 360 para gestionar.
- **Gobernanza unificada:** Las políticas, la seguridad y los controles de cumplimiento se aplican de forma centralizada.
- **Enriquecimiento entre organizaciones:** Las organizaciones de compañía pueden acceder a perfiles, perspectivas y segmentos armonizados.
- **Preparación de IA:** El conjunto de datos de toda la compañía permite una mejor capacitación y activación de modelos de IA.
- **Prueba futura:** Agregar nuevas organizaciones de compañía es sencillo; no es necesario utilizar nuevos Data 360.

**Cons**:

- **Preparación adicional:** Requiere planificación para la conectividad de organización a hogar.
- **Consideraciones sobre la latencia:** Las organizaciones de compañía en diferentes regiones pueden ver consultas más lentas.
- **Gobernanza compleja:** Si cada organización tiene necesidades de personalización muy diferentes, la regulación detallada puede ser compleja.

#### Opción C: Múltiples clústeres de Data Cloud One

En algunos casos, la gobernanza, el cumplimiento u otros requisitos de negocio pueden hacer que no sea práctico agrupar todas las organizaciones juntas. Esto puede llevar a la necesidad de implementar una solución híbrida en la que la compañía opera varios Data 360, cada uno de los cuales es la organización de inicio para un clúster diferente de organizaciones de compañía.

#### Ejemplo:

Una corporación multinacional tiene organizaciones de Salesforce en una variedad de regiones, incluyendo Europa, EE.UU. y Asia. Para cumplir con las leyes de residencia de datos regionales, proporcionan un Data 360 para cada región separada.

#### Criterios de decisión

<table>
<tr>
<th>Consideración</th>
<th>Múltiples 360 de datos independientes</th>
<th>One Shared Data 360 (Data Cloud One )</th>
</tr>
<tr>
<td><strong>Autonomía</strong></td>
<td>Alta autonomía para cada organización o unidad de negocio.</td>
<td>Gobernanza centralizada, menos autonomía por organización.</td>
</tr>
<tr>
<td><strong>Cumplimiento</strong></td>
<td>Es útil cuando se requiere una separación estricta (por ejemplo, leyes regionales).</td>
<td>Funciona mejor cuando la residencia permite la centralización.</td>
</tr>
<tr>
<td><strong>Costo</strong></td>
<td>Mayores costos de licencia y administración.</td>
<td>Más rentable; una licencia para muchas organizaciones.</td>
</tr>
<tr>
<td><strong>Gobernanza</strong></td>
<td>Fragmentado; las políticas varían por organización.</td>
<td>Políticas coherentes y centralizadas entre organizaciones.</td>
</tr>
<tr>
<td><strong>Silos de datos</strong></td>
<td>Cada organización tiene su propia vista; no hay Enterprise 360.</td>
<td>Conjunto de datos unificado, sin duplicaciones.</td>
</tr>
<tr>
<td><strong>IA/Analytics</strong></td>
<td>Limitado a los datos de cada organización.</td>
<td>Modelos de toda la compañía con mejor precisión.</td>
</tr>
<tr>
<td><strong>Complejidad</strong></td>
<td>Más instancias para gestionar, más integraciones.</td>
<td>Arquitectura más sencilla, menos piezas móviles.</td>
</tr>
<tr>
<td><strong>Desempeño</strong></td>
<td>Ideal para casos de uso dentro de la organización.</td>
<td>El acceso de la organización de compañía puede introducir latencia.</td>
</tr>
</table>

---

### 2.4 Recomendaciones

**Patrón preferido:** **Data Cloud One**

Toma como valor predeterminado una única organización de inicio con organizaciones de compañía conectadas para empresas de múltiples organizaciones.  
Esto crea un Customer 360 de toda la compañía, simplifica la gobernanza y optimiza los costos.

**Cuándo utilizar múltiples Data 360:**

Solo si el cumplimiento, la residencia o la autonomía organizativa lo requieren estrictamente. Por ejemplo, si las operaciones europeas deben permanecer completamente separadas de las operaciones estadounidenses debido a la regulación.

**Cómo elegir la organización de inicio en Data Cloud One:**

Comience considerando una de sus organizaciones principales, normalmente donde se ejecuta la mayoría de los negocios. El aprovisionamiento de Data 360 puede minimizar la complejidad y maximizar el valor temprano.

Solo si ninguna organización existente es adecuada, considere crear una organización de inicio dedicada gestionada por un equipo de Centro de excelencia.

**Principio general:**

En entornos de múltiples organizaciones, minimice el número de Data 360. Favorezca Data Cloud One como el patrón predeterminado para reducir la duplicación, activar la preparación para la IA y simplificar la gobernanza.

---

## Sección 3: Múltiples Data 360 y colaboración de datos entre organizaciones de Data 360

### 3.1 ¿Qué es la colaboración de datos entre organizaciones de Data 360?

Aunque Data Cloud One es el enfoque recomendado para la mayoría de las compañías, existen escenarios donde los clientes pueden necesitar aprovisionar múltiples instancias de Data 360. Una vez que existen varios Data 360, la unificación entre ellos no es automática.

La colaboración de datos de Data 360 a Data 360 permite a los clientes compartir objetos específicos entre instancias de Data 360 sin duplicaciones ni oportunidades en curso personalizadas. Es un mecanismo de colaboración de metadatos de copia cero diseñado para la colaboración entre Data 360.

#### Cómo funciona

- Cada Data 360 se aprovisiona en su propia organización de inicio.
- Los administradores pueden crear una colaboración de datos: una agrupación de objetos específicos que desean compartir.
- El acceso a los datos seleccionados se comparte con Data 360 de una organización de destino, donde los objetos aparecen como si estuvieran definidos localmente. Los datos subyacentes permanecen en Data 360 de origen; solo se comparte el acceso.
- Las etiquetas no se comparten. Solo los objetos sin procesar están disponibles; la organización de destino debe volver a aplicar cualquier etiqueta de gobernanza, operativa o de IA según sea necesario.

#### Diferencia clave de Data Cloud One

- En Data Cloud One, múltiples organizaciones de compañía comparten una única instancia de Data 360. Las funciones de plataforma (Agentforce, Centro de prospección, Tableau Next, etc.) se ejecutan en los mismos datos subyacentes, garantizando la coherencia.
- Al utilizar la colaboración de datos entre organizaciones de Data 360, cada organización tiene su propio Data 360. Funciones como Agentforce en la organización A y la organización B funcionan de forma independiente en su instancia local. No se produce ninguna colaboración automáticamente: se deben crear colaboraciones de datos deliberadas para colaborar únicamente en objetos específicos.

---

### 3.2 Casos de uso para la colaboración de datos entre organizaciones de Data 360

**Cumplimiento regional:**  
Un minorista multinacional aprovisiona un Data 360 en la UE y otro en EE.UU. La colaboración de datos de Data 360 a Data 360 permite a la compañía agregar perspectivas (por ejemplo, KPI de fidelidad) para compartir con la sede de EE.UU. mientras los datos sin procesar permanecen locales.

**Colaboración de unidad de negocio:**  
Un conglomerado ejecuta Data 360 separados para Retail y Insurance. El uso compartido de datos entre Data 360 permite a los usuarios acceder a un origen de datos único y autorizado sin moverse o copiar. Con la colaboración de datos entre organizaciones de Data 360, la organización de seguros recibe el segmento “Cliente de alto valor” de Retail para campañas de venta cruzada dirigidas.

**Fusiones y adquisiciones:**  
Una compañía matriz adquiere una filial con su propio Data 360. Con dos instancias para gestionar, la retención de silos de datos a corto plazo mantiene la seguridad de los datos y la integridad de SSOT. Simultáneamente, compartir datos entre dos instancias de Data 360 permite la colaboración necesaria durante la transición.

**Tableros ejecutivos federados:**  
Una multinacional distribuida entre continentes aprovisiona Data 360 individuales por región. Los ejecutivos desean una vista de desempeño trimestral federada. Cada Data 360 regional comparte perspectivas calculadas agregadas con una “Organización ejecutiva”, permitiendo la creación de reportes de toda la compañía.

#### Pros y contras de la colaboración de datos entre organizaciones de Data 360

<table>
<tr>
<th>Factor</th>
<th>Ventajas</th>
<th>Contras</th>
</tr>
<tr>
<td><strong>Residencia de datos</strong></td>
<td>Admite la separación regional mientras activa la colaboración.</td>
<td>No elimina la necesidad de gestionar múltiples Data 360.</td>
</tr>
<tr>
<td><strong>Duplicación de datos</strong></td>
<td>Cero copia; sin duplicación de objetos.</td>
<td>Requiere la selección deliberada de objetos para su inclusión en cada colaboración de datos.</td>
</tr>
<tr>
<td><strong>Gobernanza</strong></td>
<td>La colaboración es explícita y deliberada (a nivel de objeto).</td>
<td>No fluyen etiquetas ni políticas; la organización de destino debe volver a aplicar la gobernanza.</td>
</tr>
<tr>
<td><strong>Complejidad</strong></td>
<td>Activa la colaboración selectiva sin centralización.</td>
<td>Requiere la gestión de múltiples Data 360 y colaboraciones de datos.</td>
</tr>
<tr>
<td><strong>IA/Analytics</strong></td>
<td>Es posible realizar análisis/IA regionales; las perspectivas se pueden compartir entre organizaciones.</td>
<td>Ninguna IA de toda la compañía a menos que se compartan datos deliberadamente.</td>
</tr>
<tr>
<td><strong>Funciones de plataforma</strong></td>
<td>Las funciones con tecnología de Data 360 de cada organización se ejecutan de forma independiente.</td>
<td>Sin colaboración automática: riesgo de duplicación si no se diseña cuidadosamente.</td>
</tr>
<tr>
<td><strong>Costo</strong></td>
<td>Puede reducir la necesidad de oportunidades en curso de ETL.</td>
<td>Sigue teniendo el costo de múltiples Data 360. Consume créditos para consultas de datos y colaboración de datos.</td>
</tr>
</table>

#### Criterios de decisión

<table>
<tr>
<th>Consideración</th>
<th>Data Cloud One (Preferido para múltiples organizaciones)</th>
<th>Colaboración de datos entre organizaciones de Data 360</th>
</tr>
<tr>
<td><strong>Una única fuente de verdad</strong></td>
<td>✅ Sí: todas las organizaciones comparten el mismo DC.</td>
<td>❌ No: cada Data 360 tiene su propio modelo de datos.</td>
</tr>
<tr>
<td><strong>Cumplimiento</strong></td>
<td>Solo funciona cuando la residencia permite la centralización.</td>
<td>Se necesita cuando las leyes de residencia impiden la centralización.</td>
</tr>
<tr>
<td><strong>Gobernanza</strong></td>
<td>Centralizado, coherente.</td>
<td>Colaboraciones a nivel de objeto federadas y deliberadas.</td>
</tr>
<tr>
<td><strong>Complejidad</strong></td>
<td>Menos piezas móviles, más sencillo.</td>
<td>mineral complejo: requiere colaboraciones de datos de configuración y múltiples Data 360.</td>
</tr>
<tr>
<td><strong>IA/Analytics</strong></td>
<td>Modelos de IA de toda la compañía.</td>
<td>IA regional; las perspectivas se pueden compartir de forma selectiva.</td>
</tr>
<tr>
<td><strong>Funciones de plataforma</strong></td>
<td>Datos compartidos 360 significa que todas las funciones funcionan de forma coherente en Inicio + Acompañantes.</td>
<td>Las funciones se ejecutan de forma independiente en cada Data 360; la colaboración debe ser explícita.</td>
</tr>
</table>

### 3.3 Mejores prácticas

**Si su compañía tiene múltiples Data 360:**

- Utilice la colaboración de datos entre organizaciones de Data 360 para colaborar entre ellas en vez de crear oportunidades en curso personalizadas o duplicar datos.
- Comparta objetos específicos (DMO, Perspectivas calculadas, Segmentos) creando Colaboraciones de datos y otorgándolas a organizaciones de destino.
- Tenga en cuenta que las etiquetas no se comparten: la organización receptora debe volver a aplicar etiquetas (por ejemplo, gobernanza, clasificación, enriquecimiento de IA).

**Cuándo utilizar Colaboración de datos entre organizaciones de Data 360:**

- Para cumplir los requisitos normativos que impiden la centralización.
- Para mantener la autonomía de la unidad de negocio mientras activa la colaboración selectiva.
- Para proporcionar tableros ejecutivos federados entre múltiples regiones.
- Para salvar escenarios de fusiones y adquisiciones donde la consolidación no es posible de inmediato.

**Diseñar cuidadosamente**

La colaboración debe ser deliberada y específica del objeto. Evite el “exceso de colaboración”: alinee Colaboraciones de datos con necesidades de negocio y cumplimiento. Trate la colaboración de datos de Data 360 a Data 360 como una estrategia de federación, no como un reemplazo de Data Cloud One .

---

## Resumen

<ol>
<li><strong>Cada organización debe planificar el acceso a Data 360</strong><br/>
   <ul>
   <li>En adelante, todas las funciones de la plataforma Salesforce, desde Sales Cloud y Service Cloud a Agentforce, requieren conectividad de Data 360. Cada organización debe alojar una organización de inicio de Data 360 o ser una organización complementaria conectada a través de Data Cloud One.</li>
   </ul>
</li>

<li><strong>Piense en toda la compañía, no organización por organización</strong><br/>
   <ul>
   <li>Evite decisiones unilaterales de la línea de negocio tomadas de forma aislada.</li>
   <li>El aprovisionamiento debe decidirse colectivamente, idealmente por una arquitectura de compañía o consejo de gobernanza de datos. Anticipe siempre necesidades futuras de IA y análisis, que dependen de conjuntos de datos amplios y unificados.</li>
   </ul>
</li>

<li><strong>Minimizar silos de datos</strong><br/>
   <ul>
   <li>Favorezca el aprovisionamiento de Data 360 en una organización principal existente para simplificar y acelerar.</li>
   <li>En entornos de múltiples organizaciones, Data Cloud One es el patrón predeterminado para unificar organizaciones bajo un solo Data 360.</li>
   <li>Aprovisione múltiples Data 360 solo si es estrictamente necesario para el cumplimiento, la residencia o la autonomía organizativa.</li>
   </ul>
</li>

<li><strong>Diseña deliberadamente si debe ejecutar múltiples Data 360</strong><br/>
   <ul>
   <li>Configure el uso compartido de datos entre organizaciones de Data 360 para la colaboración, no oportunidades en curso de ETL personalizadas.</li>
   <li>Comparta objetos específicos (DMO, Perspectivas calculadas, Segmentos) a través de colaboraciones de datos.</li>
   <li>Recuerde: las etiquetas no se comparten y el consumo se factura a la organización de origen.</li>
   </ul>
</li>

<li><strong>Planificar la gobernanza y la propiedad pronto</strong><br/>
   <ul>
   <li>Decida si Data 360 se gestionará de forma centralizada (modelo Centro de excelencia) o se delegará a líneas de negocio. Defina funciones para administradores, equipos de seguridad y prospectos de cumplimiento.</li>
   <li>Evite la ambigüedad: la propiedad poco clara es una fuente común de fricción.</li>
   </ul>
</li>

<li><strong>Evitar accesos directos a corto plazo</strong><br/>
   <ul>
   <li>No ponga en marcha múltiples Data 360 para POC sin un plan a largo plazo; esto crea trabajo de consolidación disruptivo más adelante.</li>
   <li>En su lugar, alinee los pilotos y las implementaciones tempranas con su estrategia de aprovisionamiento de toda la compañía.</li>
   </ul>
</li>
</ol>

Estas opciones de aprovisionamiento son críticas porque la plataforma Salesforce está evolucionando hacia un modelo Data 360 first, donde cada función, desde la segmentación de clientes hasta la fundamentación de agentes de IA, dependerá de ello. Las decisiones que tome hoy sentarán las bases para la eficacia con la que su compañía unifica datos de clientes, la rapidez con la que puede adoptar nuevas funciones de Salesforce y la confianza con la que puede ampliar la IA en su negocio. Para tener éxito, debe aprovisionar cuidadosamente, minimizar la duplicación, alinearse con los requisitos de cumplimiento, gobernar deliberadamente y pensar a largo plazo. En última instancia, el aprovisionamiento de Data 360 es el primer paso para que los datos, la IA y CRM funcionen juntos como una plataforma cohesionada.

#

## Acerca de los autores

Kunal Goyal es Director de Gestión de productos en Salesforce, centrado en el avance de la arquitectura de múltiples organizaciones y la capacidad de ampliación dentro de Data 360. Desde 2017, ha liderado múltiples iniciativas y productos centrados en la colaboración entre organizaciones y el diseño de sistemas de múltiples arrendatarios. Kunal es uno de los Prospectos de arquitectura de mejores prácticas de Data 360 y el propietario del producto para las experiencias de Data Cloud One, configuración, aprovisionamiento y administración.

Erin Wagner Tidwell es redactora técnica principal y diseñadora de contenido para Data 360. Lleva en Salesforce desde 2013. Está dedicada a facilitar la comprensión y el uso de Data 360 a través de documentación técnica clara, coherente y precisa y comunicación en aplicación.

Yugandhar Bora es Arquitecto de Ingeniería de Software en Salesforce, especializado en arquitectura de datos dentro de la plataforma Aplicaciones de inteligencia y datos. Lidera iniciativas de la junta de revisión de arquitectura de negocio (EARB) centradas en la gobernanza de datos y modelos de datos unificados, mientras contribuye a soluciones de aprovisionamiento de plataforma automatizadas.

Samarpan Jain es Arquitecto principal de Salesforce especializado en Commerce Cloud, integración de plataforma y arquitectura interinstitucional. Uno de los empleados con más antigüedad de Salesforce, lidera iniciativas clave que incluyen el cumplimiento de residencia de datos para clientes gubernamentales y sistemas de atribución de uso de Data 360.

<!-- document id=dee6ed21c18f8e4d176b2e276b315e85f3d3b62df559cebc7e3b25da73c4c1a1 url=/architect/next/es-mx/decision-guides/guides/event-driven.md -->

# Uso de las herramientas y los patrones correctos para arquitecturas dirigidas por eventos

## Descripción general

Las arquitecturas dirigidas por eventos admiten la producción y el consumo eficientes de eventos, que comunican cambios de estado del sistema o la aplicación. Estas arquitecturas permiten conexiones flexibles entre sistemas y admiten procesos y actualizaciones casi en tiempo real que funcionan entre sistemas. Aunque las ventajas de las arquitecturas dirigidas por eventos son fáciles de ver, los detalles de implementación no siempre son tan claros. ¿Qué funciones necesita tener en cuenta en patrones arquitectónicos dirigidos por eventos? ¿Qué problemas específicos resuelven estos patrones? ¿Qué consideraciones especiales se aplican a sus soluciones y cuáles son los patrones óptimos para abordarlas?

Esta guía presenta patrones utilizados para crear arquitecturas dirigidas por eventos óptimas cuando se trabaja con tecnologías de Salesforce. También analiza herramientas de eventos disponibles en Salesforce y proporciona recomendaciones de herramientas para una selección de casos de uso. Para obtener información acerca de integraciones a nivel de datos que implican Salesforce, consulte nuestra [Guía de decisiones](/docs/architect/es-mx/decision-guides/guide/data-integration) de integración de datos.

## Comida para llevar

- **Utilice arquitecturas dirigidas por eventos para procesos que no requieren respuestas síncronas a solicitudes.** Los patrones descritos en esta guía están diseñados para la coherencia, la capacidad de ampliación y la reutilización de datos, lo que ayuda a mantener la deuda técnica al mínimo a medida que evoluciona el panorama de aplicaciones de su organización. (Consulte [Bien arquitectado - Rendimiento](/docs/architect/es-mx/well-architected/guide/reliable#rendimiento) para obtener más información.)

- **Si MuleSoft u otra solución de Enterprise Service Bus (ESB) forma parte de su panorama existente, utilícela donde sea posible.** Estas soluciones están creadas específicamente para admitir patrones de arquitectura dirigidos por eventos y tienen potentes funciones que le permiten reutilizar integraciones en su compañía.

- **Utilice la API Pub/Sub para cualquier patrón de publicación/suscripción futuro en vez de crear sus propios controladores de eventos utilizando otras API, incluyendo la API de transmisión.** Ahora que la API Pub/Sub está disponible de forma general, utilícela para cualquier nuevo patrón de publicación/suscripción. Planifique migrar comunicaciones de eventos existentes utilizando otras API de plataforma, como la API de transmisión o servicios Apex personalizados, a la API Pub/Sub cuando sea factible hacerlo.

- **Los eventos de plataforma y Captura de datos de cambios (CDC) son los mecanismos preferidos para publicar cambios de registro y campo que necesitan ser consumidos por otros sistemas.** No recomendamos utilizar PushTopic y eventos genéricos para nuevas implementaciones. Salesforce seguirá admitiendo PushTopic y eventos genéricos dentro de las funciones actuales, pero no tiene intención de realizar más inversiones en esta tecnología.

## Productos en ámbito

<table style="border:none;width:100%">
  <tbody>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: Salesforce Platform logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/salesforce.svg" alt="Plataforma Salesforce"></td>
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://www.salesforce.com/platform/agentforce-platform">Salesforce Platform</a> es una plataforma integral dirigida por IA que unifica empleados, agentes de IA autónomos, datos de compañía y aplicaciones en un único sistema de confianza para mejorar la productividad y la experiencia del cliente. Permite la creación de una "compañía agencia" conectando aplicaciones Customer 360, Data Cloud y Slack para la automatización de extremo a extremo.</td>
    </tr>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: MuleSoft logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://architect.salesforce.com/ns-assets/logos/mulesoft-new.png" alt="MuleSoft"></td>
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://www.salesforce.com/mulesoft/">MuleSoft</a> es la plataforma de integración líder de Salesforce que permite a las organizaciones conectar aplicaciones, datos y dispositivos en entornos locales y de nube. MuleSoft es una plataforma que proporciona a TI las plataformas para desbloquear datos entre sistemas, desarrollar marcos de trabajo de automatización e integración ampliables y crear experiencias conectadas diferenciadas rápidamente.</td>
    </tr>
  </tbody>
</table>

## Puntos de decisión

Las arquitecturas dirigidas por eventos (EDA) se recomiendan para escenarios que requieren notificaciones casi en tiempo real, distribuyendo la carga de procesamiento para mensajes de gran volumen o complejos e integrando sistemas como IoT y dispositivos móviles que requieren resiliencia de conectividad a través de colas. Sin embargo, los EDA no deben implementarse para procesos que exigen respuestas humanas inmediatas y síncronas, ya que están diseñados para la ejecución asíncrona. Tampoco se ajustan bien si los datos de origen cambian con tan poca frecuencia que un patrón más sencillo como el procesamiento por lotes sería suficiente.

### Cuándo utilizar una arquitectura dirigida por eventos

Estos son varios escenarios comunes que a menudo se ajustan bien a una arquitectura dirigida por eventos:

<table style="width:100%">
<thead>
<tr><th scope="col">Punto de decisión</th><th scope="col">Directrices</th></tr>
</thead>
<tbody>
<tr><td><strong>Notificaciones casi en tiempo real</strong></td><td>Los patrones de arquitectura dirigidos por eventos como publicación/suscripción, fanout y transmisión tienden a funcionar bien en escenarios donde múltiples aplicaciones necesitan ser notificadas de cambios de estado o actualizaciones de registros casi en tiempo real.</td></tr>
<tr><td><strong>Procesamiento paralelo</strong></td><td>Patrones como publicar/suscribir tienden a funcionar bien en escenarios donde grandes volúmenes de datos o mensajes altamente complejos requieren distribuir la carga de procesamiento entre múltiples sistemas.</td></tr>
<tr><td><strong>Lecturas de gran volumen</strong></td><td>Los patrones Mensajes pasados y Colocación en cola se utilizan habitualmente en escenarios donde las organizaciones experimentan aumentos y el volumen de mensajes que se están produciendo puede superar la capacidad de los suscriptores para procesarlos inmediatamente.</td></tr>
<tr><td><strong>Escrituras de gran volumen</strong></td><td>Los patrones de Transmisión y Colas funcionan bien en muchos escenarios donde las organizaciones experimentan aumentos en el número de mensajes producidos.</td></tr>
<tr><td><strong>Envío de los mismos datos a diferentes sistemas</strong></td><td>Aunque la publicación/suscripción tiende a ser una solución bastante común para organizaciones que necesitan enviar los mismos datos a múltiples sistemas, la mayoría de los patrones cubiertos aquí pueden solucionarla. Asegúrese de revisarlos en detalle para encontrar el mejor ajuste.</td></tr>
<tr><td><strong>Introducción frecuente de nuevos sistemas o dispositivos</strong></td><td>Los patrones de publicación/suscripción, Transmisión y Colocación en cola tienden a funcionar bien para escenarios donde el panorama general tiende a estar en flujo, con nuevos sistemas y dispositivos agregados regularmente. En este escenario, un nuevo sistema o dispositivo simplemente necesita convertirse en un suscriptor del bus de eventos o asociado con una cola, para comenzar a recibir mensajes en vez de requerir una integración de punto a punto personalizada.</td></tr>
<tr><td><strong>Dispositivos IoT</strong></td><td>Debido a que los dispositivos de IoT normalmente entregan actualizaciones frecuentes y también pueden generar una oleada de mensajes en algunos escenarios, los patrones de Transmisión y Colocación en cola tienden a funcionar bien al integrarlos en un entorno de TI.</td></tr>
<tr><td><strong>Dispositivos y sistemas móviles sin conexión</strong></td><td>Los dispositivos móviles que necesitan trabajar en áreas con acceso a Internet de baja calidad o inexistente o sistemas que podrían estar sin conexión en el momento de la entrega de los mensajes se beneficiarán del patrón Colas, que les permite conectarse a sus colas y recuperar cualquier mensaje relevante una vez que vuelvan a estar conectados.</td></tr>
</tbody>
</table>

La mayoría de las grandes organizaciones tienen escenarios de TI complejos que tienen una combinación de sistemas con diferentes funciones. Es posible, o quizás probable, que su organización tenga sistemas heredados que no admitan integraciones dirigidas por eventos. También puede tener casos de uso donde las integraciones dirigidas por eventos no tienen sentido, incluso si los sistemas las admitirán (por ejemplo, transferencias de archivos SFTP desde terceros). Si da un paso atrás y observa el panorama de TI de su organización en su conjunto, lo más probable es que, al igual que con otras soluciones arquitectónicas, emplee una mezcla de patrones para dar cobertura a diferentes escenarios. Cuando decida hacer que la gestión de eventos sea su enfoque preferido para las integraciones, piense en ella como otra herramienta en su caja de herramientas. Puede y debe utilizarse en los escenarios correctos, pero no es un enfoque a imponer en cada sistema. Desarrollar una estrategia de integración integral le ayudará a determinar cuándo los patrones descritos en esta guía pueden o no ser apropiados.

### Cuándo no utilizar una arquitectura dirigida por eventos

Muchos escenarios requieren arquitecturas dirigidas por eventos, y en algunos escenarios, las arquitecturas dirigidas por eventos funcionarán incluso si no son las más adecuadas. Pero en algunos escenarios, las arquitecturas dirigidas por eventos simplemente no se deben utilizar. Estas son algunas preguntas de punto de decisión para ayudarle a identificar estos escenarios:

<table style="width:100%">
<thead>
<tr><th scope="col">Punto de decisión</th><th scope="col">Directrices/Preguntas para formular</th></tr>
</thead>
<tbody>
<tr><td><strong>Requisitos de negocio</strong></td><td>¿Existe una necesidad de negocio genuina para cualquiera de las funciones descritas en la sección [Cuándo utilizar una arquitectura dirigida por eventos](#cuándo utilizar una arquitectura dirigida por eventos)?</td></tr>
<tr><td><strong>Requisitos técnicos</strong></td><td>¿La integración que está diseñando se ajusta de forma obvia a un patrón diferente, como la virtualización de datos, los lotes o las solicitudes/respuestas? En otras palabras, ¿está intentando encajar una clavija cuadrada en un agujero redondo?</td></tr>
<tr><td><strong>Procesos que requieren que los humanos esperen respuestas</strong></td><td>Cualquier integración que implique un humano esperando una respuesta del sistema de destino no es una buena opción para arquitecturas dirigidas por eventos, ya que están diseñadas para la ejecución asíncrona y no pueden garantizar un tiempo de respuesta. Considere si procesos como este son óptimos para su organización antes de implementar soluciones técnicas. Consulte [Well-Architected - Process Design](/docs/architect/es-mx/well-architected/guide/automated#diseño-de-procesos) para obtener más información.</td></tr>
<tr><td><strong>Cambiar datos de origen con poca frecuencia</strong></td><td>Si los datos en su sistema de origen cambian con tan poca frecuencia que las actualizaciones periódicas son suficientes, es probable que pueda simplificar su arquitectura utilizando [patrones por lotes] (https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_batch_data_sync.htm) en vez de patrones dirigidos por eventos.</td></tr>
<tr><td><strong>Requisitos de implementación</strong></td><td>¿La mayoría de los sistemas implicados en su solución admiten arquitecturas dirigidas por eventos? ¿Qué se requeriría para utilizar arquitecturas dirigidas por eventos con los sistemas que no las admiten (por ejemplo, actualizaciones, personalizaciones o middleware)? ¿Qué nivel de esfuerzo sería necesario para cumplir estos requisitos?</td></tr>
<tr><td><strong>Estabilidad de estructura de mensajes</strong></td><td>¿Con qué frecuencia tendrán que cambiar sus estructuras de mensajes? ¿Qué sistemas se verán afectados por dicho cambio y cuál será el proceso de rehabilitación?</td></tr>
<tr><td><strong>Gobernanza organizativa</strong></td><td>¿Tiene una estructura de gobernanza establecida para garantizar que todas las partes interesadas estén informadas y puedan ponderar los cambios en las estructuras de mensajes, desencadenadores y otras decisiones relacionadas con la arquitectura y los procesos?</td></tr>
<tr><td><strong>Conjuntos de habilidades requeridos</strong></td><td>¿Tiene su personal experiencia con arquitecturas dirigidas por eventos y sabrán cómo brindarles asistencia?</td></tr>
</tbody>
</table>

## Casos de uso

Hay una variedad de patrones de arquitectura dirigidos por eventos. Algunos son patrones de propósito general que se pueden aplicar en casos de uso que no tienen ningún requisito especial fuera de estar dirigidos por eventos; por ejemplo, consulte [Bien arquitectado - Interoperabilidad](/docs/architect/es-mx/well-architected/guide/composable#interoperabilidad). Otros patrones son aplicables a los casos de uso específicos tratados aquí, como integraciones que implican grandes volúmenes de datos o escenarios que requieren una retención de mensajes más larga.

### Patrones de un vistazo

La tabla siguiente compara atributos de los patrones descritos en este documento. Utilícelo como una referencia rápida cuando necesite identificar posibles patrones para un caso de uso concreto.

<table style="width:100%">
<thead>
<tr><th scope="col">Patrón</th><th scope="col">Casi en tiempo real</th><th scope="col">Copiar mensaje exclusivo</th><th scope="col">Entrega de garantía</th><th scope="col">Reducir el tamaño de mensajes</th><th scope="col">Transformar datos</th></tr>
</thead>
<tbody>
<tr><td>Publicar / Suscribir</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
<tr><td>Fanout</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
<tr><td>Mensajes pasados</td><td>✓</td><td></td><td>✓</td><td>✓</td><td>✓</td></tr>
<tr><td>Transmisión</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
<tr><td>Colocación en cola</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
</tbody>
</table>

### Herramientas para arquitectura dirigida por eventos

Salesforce ofrece múltiples herramientas para ayudarle a solucionar sus casos de uso dirigidos por eventos. Esta tabla contiene una descripción general de alto nivel de las herramientas disponibles.

<table style="width:100%">
<thead>
<tr><th scope="col"></th><th scope="col">Herramienta</th><th scope="col">Descripción</th><th scope="col">Habilidades requeridas</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/general/">Plataforma Anypoint</a></td><td>Plataforma que activa la integración de datos utilizando capas de API.</td><td>Código pro</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Conector Salesforce Pub/Sub</a></td><td>API de Connector para Pub/Sub, que proporciona una única interfaz para publicar y suscribirse a eventos de plataforma, eventos de monitoreo de eventos en tiempo real y eventos Captura de datos de cambios.</td><td>Código pro</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/jms-connector/latest/">MuleSoft Anypoint JMS Connector</a></td><td>Conector que permite enviar y recibir mensajes a colas y temas para cualquier servicio de mensajes que implemente la especificación Servicio de mensajes Java (JMS).</td><td>Código pro</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Conector para mover datos entre Apache Kafka y aplicaciones y servicios de negocio.</td><td>Código pro</td></tr>
<tr><th scope="row"></th><td><a href="https://github.com/SolaceProducts/pubsubplus-connector-mule-docs/blob/main/doc/user-guide.md">Conector de consola Anypoint de MuleSoft</a></td><td>Un conector para corredores de eventos PubSub+ de Solace con integración de API nativa utilizando el SDK de Java JCSMP</td><td>Código pro</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">MuleSoft Anypoint MQ Connector</a></td><td>Un servicio de mensajería en la nube de múltiples arrendatarios que permite a los clientes realizar mensajería asíncrona avanzada entre sus aplicaciones.</td><td>Código pro</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">MuleSoft Anypoint MQTT Connector</a></td><td>Una extensión MuleSoft que cumple el protocolo MQTT (Message Queing Telemetry Transport).</td><td>Código pro</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">Conector AMQP de Mulsoft Anypoint</a></td><td>Un conector que permite a su aplicación publicar y consumir mensajes utilizando un broker compatible con AMQP 0.9.1.</td><td>Código pro</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/release-notes/platform/event-driven-api">API dirigida por eventos de MuleSoft Anypoint (ASync)</a></td><td>Lenguaje que distingue entre la industria y que admite la publicación de API dirigidas por eventos separándolas en capas de evento, canal y transporte.</td><td>Código pro</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Servicio de mensajería en la nube de múltiples arrendatarios que permite a los clientes realizar mensajería asíncrona avanzada entre sus aplicaciones.</td><td>Código pro</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mule-runtime/latest/streaming-about">Transmisiones de datos de MuleSoft Anypoint</a></td><td>Marco de trabajo disponible en MuleSoft Anypoint para publicar y suscribirse a datos de transmisión.</td><td>Código pro</td></tr>
<tr><th scope="row">Plataforma Salesforce</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka on Heroku</a></td><td>Complemento de Heroku que proporciona Apache Kafka como un servicio con integración de plataforma completa en la plataforma Heroku.</td><td>Código pro</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Captura de datos</a></td><td>Registro de eventos de cambio, que publica los cambios en registros de Salesforce. Los cambios incluyen la creación de un nuevo registro, actualizaciones en un registro existente, la eliminación de un registro y la anulación de la eliminación de un registro.</td><td>Código bajo a código profesional</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging.htm">Mensajes salientes</a></td><td>Acciones que envían mensajes XML a extremos externos cuando se actualizan valores de campo en Salesforce.</td><td>Código bajo</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Eventos de plataforma</a></td><td>Mensajes seguros y ampliables que contienen datos de eventos personalizados.</td><td>Código bajo a código profesional</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">API Pub/Sub</a></td><td>API que activa suscripciones a eventos de plataforma, eventos de Captura de datos de cambios y/o eventos de Monitoreo de eventos en tiempo real.</td><td>Código pro</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Retransmisiones de eventos</a></td><td>Activa eventos de plataforma y Captura de datos de cambios para enviar desde Salesforce a Amazon EventBridge. Tenga en cuenta que las retransmisiones de eventos solo se conectan a AWS Eventbridge.</td><td>Código bajo</td></tr>
<tr><th scope="row"></th><td></td><td></td><td></td></tr>
</tbody>
</table>

### Publicar/Suscribir

Cuando un registro crítico cambia de estado en una aplicación principal (por ejemplo, el estado de un pedido pasa de "Procesando" a "Enviado"), es probable que varios otros sistemas requieran una notificación casi en tiempo real para realizar sus tareas respectivas. Una necesidad de negocio específica surge cuando el volumen de estos cambios es alto y los mensajes son complejos, lo que hace que las integraciones punto a punto tradicionales sean onerosas y difíciles de mantener. Establecer conexiones frágiles y personalizadas para cada aplicación dependiente individual lleva a deudas técnicas e inhibe la capacidad de la organización de ampliarse rápidamente. Se necesita un enfoque de integración sólido para gestionar estas sincronizaciones de datos frecuentes sin acoplar el sistema de origen directamente a cada sistema consumidor.

#### El patrón Publicar/Suscribir

El siguiente diagrama representa un patrón típico de publicación/suscripción con múltiples publicadores y suscriptores compartiendo datos a través de un bus de eventos. Este patrón fundacional forma la base para los patrones más específicos que se pueden encontrar en el resto de esta guía. Algunas características clave de este patrón son:

- No hay conexión directa entre publicadores y suscriptores. Los publicadores simplemente envían mensajes a un bus de eventos, que los transmite a cualquier otro sistema que desee escucharlos.

- El mismo sistema puede ser un publicador y un suscriptor.

- Los sistemas pueden publicar o suscribirse a múltiples tipos de eventos.

- Al igual que con todos los patrones de esta guía, el patrón de publicación/suscripción recae en una categoría de patrón de integración general conocida como invocación de procedimiento remoto (RPI) o simplemente ["disparar y olvidar".](/docs/architect/es-mx/fundamentals/guide/integration-patterns#invocación-de-procesos-remotos-disparar-y-olvidar)

<!-- Image: Publish/subscribe pattern diagram (Level 2) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Publish - Subscribe L2.png" alt="Este diagrama Nivel 2 muestra un ejemplo del patrón de publicación / suscripción que incluye múltiples publicadores, múltiples suscriptores y múltiples eventos que se entregan a través de canales en un bus de eventos. En este patrón, el mismo sistema puede ser un publicador y un suscriptor y un sistema puede suscribirse a múltiples eventos.">

#### Herramientas relevantes para el patrón Publicar/Suscribir

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Comportamiento y flujo de eventos</th><th colspan="2" scope="colgroup">Consideraciones sobre la carga</th></tr>
<tr><th scope="col">Herramientas disponibles</th><th scope="col"></th><th scope="col">Habilidades requeridas</th><th scope="col">Publicar vía</th><th scope="col">Suscribirse a través</th><th scope="col">Periodo de reproducción</th><th scope="col">Estructura de carga</th><th scope="col">Límites de carga</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/general/">Plataforma Anypoint</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Conector Salesforce Pub/Sub</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/jms-connector/latest/">MuleSoft Anypoint JMS Connector</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://github.com/SolaceProducts/pubsubplus-connector-mule-docs/blob/main/doc/user-guide.md">Conector de consola Anypoint de MuleSoft</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">MuleSoft Anypoint MQ Connector</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">MuleSoft Anypoint MQTT Connector</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">Conector AMQP de Mulsoft Anypoint</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/release-notes/platform/event-driven-api">API dirigida por eventos de MuleSoft Anypoint (ASync)</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row">Plataforma Salesforce</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka on Heroku</a></td><td>Código pro</td><td>API, registrar cambios en Postgres de Heroku</td><td>N/A</td><td>1-6 semanas</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Usuario definido</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Usuario definido</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Captura de datos</a></td><td>Código bajo a código profesional</td><td>Cambios de registro</td><td>Apex, API, componentes web Lightning (LWC)</td><td>3 días</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Predefinido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging.htm">Mensajes salientes*</a></td><td>Código bajo</td><td>Reglas de flujo y flujo de trabajo</td><td>N/A</td><td>24 horas</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging_wsdl.htm">Usuario definido</a></td><td>100 notificaciones por mensaje</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Eventos de plataforma</a></td><td>Código bajo a código profesional</td><td>API, Apex, Flujo</td><td>Apex, API, Flow, LWC</td><td>3 días</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Usuario definido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">API Pub/Sub</a></td><td>Código pro</td><td>API o API Pub/Sub, Apex, Flujo</td><td>API Pub/Sub</td><td>3 días</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Usuario definido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Retransmisiones de eventos**</a></td><td>Código bajo</td><td>Eventos de plataforma, Captura de datos de cambios</td><td>API</td><td>3 días</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Usuario definido</a></td><td>1 MB</td></tr>
<tr><td colspan="8">*Salesforce seguirá admitiendo mensajes salientes dentro de las funciones actuales, pero no tiene intención de realizar más inversiones en esta tecnología. **Las retransmisiones de eventos solo se conectan a AWS Eventbridge</td></tr>
</tbody>
</table>

### Fanout

Cuando una organización necesita enviar actualizaciones instantáneas a un gran número de aplicaciones cliente, como notificaciones distribuidas o mensajes SMS a dispositivos móviles, el proceso tradicional de crear transmisiones exclusivas para cada destinatario se convierte rápidamente en un cuello de botella de capacidad de ampliación. La necesidad de negocio principal, en este caso, es la distribución rápida y de alto desempeño de una sola información (como una alerta de cuenta o un aviso de cambio de servicio crítico) a numerosas aplicaciones de extremo de forma simultánea. Un enfoque simplificado para cumplir este requisito implica el enrutamiento de todos los mensajes a través de una única cola, que actúa como el punto central de la información de eventos para todos los sistemas que consumen. Este enfoque mejora el desempeño eliminando la necesidad de gestionar muchas copias de mensajes separadas.

#### El patrón Fanout

Con el patrón fanout, los mensajes se entregan a uno o múltiples destinos (es decir, clientes o suscriptores que escuchan) a través de una única cola de mensajes. Los suscriptores recuperan el mismo mensaje de la cola, en vez de su propia copia exclusiva. (Tenga en cuenta que aunque esto mejora el desempeño, también puede hacer más difícil verificar si un suscriptor concreto recibió o no el mensaje.)

<!-- Image: Fanout pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Fanout L3.png" alt="Este diagrama de implementación y documentación de Nivel 3 muestra un ejemplo del patrón de abanico. Representa un evento que se publica y se escribe en una única cola cuando se modifica un registro a través de una interacción de usuario, un flujo o un trabajo por lotes. El sistema de suscriptor tiene múltiples servicios que reciben el mismo evento desde la cola de mensajes.">

#### Herramientas relevantes para el patrón Fanout

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Comportamiento y flujo de eventos</th><th colspan="2" scope="colgroup">Consideraciones sobre la carga</th></tr>
<tr><th scope="col">Herramientas disponibles</th><th scope="col"></th><th scope="col">Habilidades requeridas</th><th scope="col">Publicar vía</th><th scope="col">Suscribirse a través</th><th scope="col">Periodo de reproducción</th><th scope="col">Estructura de carga</th><th scope="col">Límites de carga</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/jms-connector/latest/">MuleSoft Anypoint JMS Connector</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Conector Salesforce Pub/Sub</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://github.com/SolaceProducts/pubsubplus-connector-mule-docs/blob/main/doc/user-guide.md">Conector de consola Anypoint de MuleSoft</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">MuleSoft Anypoint MQ Connector</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">MuleSoft Anypoint MQTT Connector</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">Conector AMQP de Mulsoft Anypoint</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row">Plataforma Salesforce</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka on Heroku</a></td><td>Código pro</td><td>API, registrar cambios en Postgres de Heroku</td><td>N/A</td><td>1-6 semanas</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Usuario definido</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Usuario definido</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Captura de datos</a></td><td>Código bajo a código profesional</td><td>Cambios de registro</td><td>Apex, API, componentes web Lightning (LWC)</td><td>3 días</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Predefinido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Eventos de plataforma</a></td><td>Código bajo a código profesional</td><td>API, Apex, Flujo</td><td>Apex, API, Flow, LWC</td><td>3 días</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Usuario definido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">API Pub/Sub</a></td><td>Código pro</td><td>API Pub/Sub o Apex, API, Flujo</td><td>API Pub/Sub</td><td>3 días</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Usuario definido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Retransmisiones de eventos*</a></td><td>Código bajo</td><td>Eventos de plataforma, Captura de datos de cambios</td><td>API</td><td>3 días</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Usuario definido</a></td><td>1 MB</td></tr>
<tr><td colspan="8">*Las retransmisiones de eventos solo envían datos a AWS Eventbridge</td></tr>
</tbody>
</table>

### Mensajes pasados

Algunos escenarios de eventos se caracterizan por una afluencia significativa de volumen de mensajes que amenaza con abrumar la capacidad de los procesos de sincronización y transformación, o por una lógica compleja de múltiples pasos requerida para procesar y transformar datos de eventos.

Algunos ejemplos incluyen:

- **Picos de volumen estacionales:** Puede haber picos de volumen que los minoristas online experimentan cuando una selección de sus productos está "en temporada". Cuando un gran número de clientes están realizando compras al mismo tiempo, el número de eventos generados puede superar temporalmente la capacidad de los procesos de sincronización y transformación. Consulte [Bien arquitectado: Gestión](/docs/architect/es-mx/well-architected/guide/automated#gestión-de-datos) de datos para obtener más información.

- **Gestión de casos o reclamaciones:** Las compañías basadas en servicio pueden experimentar aumentos en el número de casos o reclamaciones durante cortes.

- **Transformaciones de datos complejas:** Las organizaciones que requieren lógica compleja para transformar mensajes a menudo están preocupadas por que los eventos se generen más rápido de lo que se pueden transformar.

#### El patrón de mensajes pasados

Este patrón soluciona el reto de que los mensajes se generen más rápido de lo que se pueden transformar. Garantiza que los grandes volúmenes de mensajes y las manipulaciones de datos requeridas se puedan gestionar de forma fiable, incorporando una plataforma de mensajes de transmisión y segmentando la lógica de gestión de mensajes en componentes exclusivos.

El patrón Mensajes pasados funciona segmentando la lógica de gestión de mensajes en múltiples componentes:

- Un componente gestiona el enrutamiento de mensajes, determinando las transformaciones requeridas y el destino final.

- Un conjunto separado de componentes gestiona diferentes capas de transformación de mensajes (por ejemplo, asignaciones de campos, relaciones de objetos, etc.).

- El último componente redacta el mensaje modificado final.

<!-- Image: Passed messages pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Passed Messages L3.png" alt="Este diagrama de implementación y documentación de Nivel 3 muestra un ejemplo de un flujo de proceso para el patrón de mensajes pasados que incluye un publicador, un suscriptor y un mensaje. El mensaje se divide en múltiples partes, que se transforman individualmente y luego se vuelven a ensamblar antes de enviarse al suscriptor.">

#### Herramientas relevantes para el patrón de mensajes pasados

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Comportamiento y flujo de eventos</th><th colspan="2" scope="colgroup">Consideraciones sobre la carga</th></tr>
<tr><th scope="col">Herramientas disponibles</th><th scope="col"></th><th scope="col">Habilidades requeridas</th><th scope="col">Publicar vía</th><th scope="col">Suscribirse a través</th><th scope="col">Periodo de reproducción</th><th scope="col">Estructura de carga</th><th scope="col">Límites de carga</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Conector Salesforce Pub/Sub</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row">Plataforma Salesforce</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka on Heroku</a></td><td>Código pro</td><td>API, registrar cambios en Postgres de Heroku</td><td>N/A</td><td>1-6 semanas</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Usuario definido</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Usuario definido</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Captura de datos</a></td><td>Código bajo a código profesional</td><td>Cambios de registro</td><td>Apex, API, componentes web Lightning (LWC)</td><td>3 días</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Predefinido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Eventos de plataforma</a></td><td>Código bajo a código profesional</td><td>API, Apex, Flujo</td><td>Apex, API, Flow, LWC</td><td>3 días</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Usuario definido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">API Pub/Sub</a></td><td>Código pro</td><td>API o API Pub/Sub, flujo Apex</td><td>API Pub/Sub</td><td>3 días</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Usuario definido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Retransmisiones de eventos*</a></td><td>Código bajo</td><td>Eventos de plataforma, Captura de datos de cambios</td><td>API</td><td>3 días</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Usuario definido</a></td><td>1 MB</td></tr>
<tr><td colspan="8">*Las retransmisiones de eventos solo envían datos a AWS Eventbridge</td></tr>
</tbody>
</table>

### Transmisión

Algunos productores generan una transmisión continua de eventos. Un ejemplo común es la transmisión de medios, que implica interacciones de usuario que se producen de forma natural como eventos discretos. Múltiples sistemas deben reaccionar al mismo comportamiento de usuario simultáneamente sin bloquear la experiencia de transmisión principal.

Considere los eventos para una plataforma de transmisión de música. Estos pueden incluir:

- Realizar seguimiento de eventos iniciados/en pausa/omitidos

- Escuchar eventos de sesión con marcas de tiempo

- Eventos de creación/modificación de listas de reproducción

- Eventos de colaboración en redes sociales

- Descargar para escuchar sin conexión

#### El patrón de transmisión

En el patrón Transmisión, los suscriptores acceden a cada transmisión de evento y procesan los eventos en el orden exacto en que se reciben. Se envían copias exclusivas de cada transmisión de mensajes a cada suscriptor, lo que permite entregar contenido específico del suscriptor e identificar qué suscriptores reciben qué transmisiones.

<!-- Image: Streaming pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Streaming - L3.png" alt="Este diagrama de implementación y documentación de Nivel 3 muestra un ejemplo del patrón de transmisión que representa una transmisión de eventos que se están publicando. Los suscriptores que están escuchando las transmisiones las reciben y las procesan en consecuencia.">

#### Herramientas relevantes para el patrón de transmisión

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Comportamiento y flujo de eventos</th><th colspan="2" scope="colgroup">Consideraciones sobre la carga</th></tr>
<tr><th scope="col">Herramientas disponibles</th><th scope="col"></th><th scope="col">Habilidades requeridas</th><th scope="col">Publicar vía</th><th scope="col">Suscribirse a través</th><th scope="col">Periodo de reproducción</th><th scope="col">Estructura de carga</th><th scope="col">Límites de carga</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/mule-runtime/latest/streaming-about">Transmisiones de datos de MuleSoft Anypoint</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Conector Salesforce Pub/Sub</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row">Plataforma Salesforce</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka on Heroku</a></td><td>Código pro</td><td>API, registrar cambios en Postgres de Heroku</td><td>N/A</td><td>1-6 semanas</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Usuario definido</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Usuario definido</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">API Pub/Sub</a></td><td>Código pro</td><td>API o API Pub/Sub, flujo Apex</td><td>API Pub/Sub</td><td>3 días</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Usuario definido</a></td><td>1 MB</td></tr>
</tbody>
</table>

#### Gestión de pedidos de eventos transmitidos

Para que una transmisión tenga sentido, todos sus eventos y sus mensajes asociados deben estar en el orden correcto. Si origina los datos en una transmisión desde diferentes sistemas, deberá incorporar lógica de pedido adicional como parte del proceso de diseño.

### Colocación en cola

Los casos de uso en cola son omnipresentes. Algunos ejemplos incluyen:

- **Conexiones a Internet de baja calidad:** Las organizaciones de servicio de campo u otras organizaciones donde los equipos con dispositivos móviles necesitan trabajar en áreas con acceso a Internet de baja calidad o intermitente se benefician de las colas porque las aplicaciones en estos dispositivos pueden conectarse a sus colas y recuperar cualquier mensaje relevante cuando se restablece la conectividad.

- **Almacenamiento en memoria intermedia de mensajes:** Cuando el volumen de mensajes supera ocasionalmente la capacidad de procesamiento de un suscriptor y el aumento de la latencia no crea problemas adicionales, las colas pueden ser un tampón para almacenar mensajes en exceso y evitar la pérdida de datos.

- **Gestión de transporte:** Las organizaciones logísticas que necesitan monitorear sus flotas pueden utilizar este patrón para ver las rutas que está realizando cada vehículo casi en tiempo real y garantizar que los conductores son lo más eficientes posible.

- **Dispositivos IoT:** Los fabricantes a menudo utilizan sistemas que generan transmisiones rápidas de datos, y estas transmisiones pueden tener efectos descendentes en sistemas adicionales. Este patrón puede utilizarse para identificar secuencias de eventos que requieren intervención humana antes de que se produzcan fallos catastróficos que abarquen múltiples sistemas.

#### El patrón de colas

En el patrón Colas, los productores envían mensajes a colas, que mantienen los mensajes hasta que los suscriptores los recuperan. La mayoría de las colas de mensajes siguen el orden de llegada y salida (FIFO) y eliminan cada mensaje después de recuperarlo. Cada suscriptor tiene una cola exclusiva, que requiere pasos de configuración adicionales pero permite garantizar la entrega e identificar qué suscriptores recibieron qué mensajes.

<!-- Image: Queuing pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Queuing L3.png" alt="Este diagrama de implementación y documentación de Nivel 3 muestra un ejemplo del patrón de cola que representa un evento que se está publicando y redactando en una cola cuando se modifica un registro. Los suscriptores reciben copias del evento desde sus colas asociadas y realizan las actualizaciones apropiadas en sus propios registros.">

#### Herramientas relevantes para el patrón de cola

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Comportamiento y flujo de eventos</th><th colspan="2" scope="colgroup">Consideraciones sobre la carga</th></tr>
<tr><th scope="col">Herramientas disponibles</th><th scope="col"></th><th scope="col">Habilidades requeridas</th><th scope="col">Publicar vía</th><th scope="col">Suscribirse a través</th><th scope="col">Periodo de reproducción</th><th scope="col">Estructura de carga</th><th scope="col">Límites de carga</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/4.3/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Conector Salesforce Pub/Sub</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">MuleSoft Anypoint MQ Connector</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">MuleSoft Anypoint MQTT Connector</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">Conector AMQP de Mulsoft Anypoint</a></td><td>Código pro</td><td>API</td><td>API</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Como está configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuario definido</a></td><td>Ninguna</td></tr>
<tr><th scope="row">Plataforma Salesforce</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka on Heroku</a></td><td>Código pro</td><td>API, registrar cambios en Postgres de Heroku</td><td>N/A</td><td>1-6 semanas</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Usuario definido</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Usuario definido</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Captura de datos</a></td><td>Código bajo a código profesional</td><td>Cambios de registro</td><td>Apex, API, componentes web Lightning (LWC)</td><td>3 días</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Predefinido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Eventos de plataforma</a></td><td>Código bajo a código profesional</td><td>API, Apex, Flujo</td><td>Apex, API, Flow, LWC</td><td>3 días</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Usuario definido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">API Pub/Sub</a></td><td>Código pro</td><td>API o API Pub/Sub, Apex, Flujo</td><td>API Pub/Sub</td><td>3 días</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Usuario definido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Retransmisiones de eventos*</a></td><td>Código bajo</td><td>Eventos de plataforma, Captura de datos de cambios</td><td>API</td><td>3 días</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Usuario definido</a></td><td>1 MB</td></tr>
<tr><td colspan="8">*Las retransmisiones de eventos solo envían datos a AWS Eventbridge</td></tr>
</tbody>
</table>

#### Gestión de memoria y almacenamiento

Debido a la naturaleza asíncrona del patrón En cola, puede haber un retraso prolongado entre la incorporación de un mensaje a una cola y la recuperación de ese mensaje. Las colas requieren memoria o espacio de almacenamiento para albergar sus mensajes, de modo que no pueden crecer indefinidamente, lo que significa que un suscriptor que está sin conexión indefinidamente puede provocar un fallo si se acumulan suficientes mensajes en la cola. El almacenamiento en memoria intermedia de mensajes puede tener el mismo efecto si los tiempos de procesamiento de los suscriptores son demasiado largos, lo que provoca que se acumulen grandes volúmenes de mensajes en sus colas. Para mitigar estos riesgos, realice un análisis exhaustivo de los requisitos de almacenamiento para todas las colas de mensajes y, si es necesario, diseñe procesos que purgarán y desactivarán las colas si los mensajes no se recuperan en un tiempo establecido o cuando alcanzan un volumen predeterminado.

## Consideraciones no funcionales

### Migración de integraciones de punto a punto

Incluso si está completamente convencido de que una arquitectura dirigida por eventos es adecuada para su organización, es posible que esté empezando con un panorama que ya tiene un gran número de integraciones de punto a punto. Obtener financiación para un proyecto para sustituir todas sus integraciones a la vez puede ser difícil, e incluso podría no ser posible utilizar una arquitectura dirigida por eventos directamente con algunos sistemas heredados. En estos escenarios, puede adoptar un enfoque incremental para migrar a una arquitectura acoplada de forma más flexible convirtiendo las aplicaciones más críticas de negocio primero, luego convirtiendo otros sistemas a medida que se actualizan o se sustituyen en proyectos futuros. Este enfoque facilita la tarea de agregar nuevas aplicaciones al bus de eventos y permite que su panorama general de TI se mantenga escalable y resiliente a medida que se siguen agregando sistemas con el tiempo.

### Compensaciones en sistemas poco acoplados

Como arquitectos, sabemos que cada arquitectura tiene ventajas. Una arquitectura dirigida por eventos no es una excepción. Aunque un paisaje lleno de sistemas acoplados de forma flexible es altamente ampliable y resistente, también hay algunas ventajas a tener en cuenta:

- **Estrategia general de integración:** Independientemente de las herramientas y los patrones que decida utilizar, es importante empezar por crear una estrategia sobre cómo se compartirán los datos entre los diversos sistemas en el panorama de su organización. Esta estrategia debe incluir los objetivos de su organización para sus datos, cómo se pueden compartir los datos y los patrones utilizados, así como orígenes de datos, objetivos, estructuras y requisitos de propiedad y acceso.

- **Compatibilidad con sistemas heredados:** Su organización puede tener sistemas heredados que simplemente no admiten patrones de arquitectura dirigidos por eventos. Aunque es posible crear soluciones (por ejemplo, con un proceso que actúa como una transferencia suscribiéndose a eventos y luego enviando el resultado al sistema de destino a través de un medio diferente de transferencia de datos), es posible que desee considerar otros métodos de integración en este caso.

- **Cambios estructurales en mensajes:** Una vez definida y acordada la estructura de mensajes inicial entre publicadores y suscriptores, puede ser difícil cambiar, especialmente si los suscriptores son externos. Existen varias formas de solucionar este problema. Puede utilizar extremos versionados, pero asegúrese de definir y comunicar un ciclo de vida claro para cada versión de modo que sus desarrolladores no tengan que mantener demasiadas versiones simultáneamente. Si Apache Kafka en Heroku forma parte de su paisaje, también puede considerar un registro de esquemas o una herramienta similar, pero asegúrese de que los otros sistemas en su paisaje lo admiten (y lo utilizan) también.

- **Falta de visibilidad entre publicadores y suscriptores:** En la mayoría de los patrones de arquitectura dirigidos por eventos, los publicadores no conocen el estado de sus suscriptores. Por lo tanto, si un publicador envía un mensaje crítico mientras todos los suscriptores no tienen conexión, es posible que el mensaje nunca se entregue. Puede solucionar este problema haciendo uso de funciones de reproducción o agregando suscriptores redundantes que se ejecutan en servidores separados para todos los mensajes críticos.

- **Cuellos de botella de desempeño:** A medida que se amplía una arquitectura dirigida por eventos, el bus de eventos puede convertirse en un cuello de botella para la entrega de mensajes si se ve desbordado por demasiados publicadores que intentan enviar mensajes a demasiados suscriptores de forma simultánea. Puede solucionar esto aumentando la memoria y procesando recursos asignados al bus de eventos o utilizando múltiples buses de eventos para procesar diferentes tipos de mensajes en paralelo.

## Mejores prácticas relacionadas

### Implementación de arquitecturas dirigidas por eventos

Antes de implementar una arquitectura dirigida por eventos, considere si realmente necesita utilizar una en primer lugar. La sección anterior describe escenarios de negocio comunes que se ajustan bien a cada patrón de arquitectura dirigido por eventos. También puede leer más en [Bien arquitectado - Interoperabilidad](/docs/architect/es-mx/well-architected/guide/composable#interoperabilidad). Revise los retos a tener en cuenta al implementar arquitecturas dirigidas por eventos para determinar si los patrones que tiene en mente son los más adecuados para sus casos de uso específicos.

Tenga en cuenta que aunque la mayoría de los escenarios cubiertos en esta guía implican integraciones, las arquitecturas dirigidas por eventos también se pueden utilizar para enviar mensajes dentro de una única organización de Salesforce a través del uso de eventos de plataforma, por ejemplo. Asegúrese de tener en cuenta cualquier [límite de asignación](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) de eventos aplicable cuando diseñe procesos que utilizan eventos de plataforma como un sistema de mensajería interno.

### Evitar antipatrones

Frecuentemente, los antipatrones alrededor de arquitecturas dirigidas por eventos provienen del uso de eventos como una solución para comunicaciones internas en una organización de Salesforce. Los antipatrones comunes incluyen:

- **Publicación de eventos desde desencadenadores Apex asociados con el mismo objeto de evento:** Esto dará como resultado un bucle de desencadenador infinito.

- **Publicación de eventos desde Apex antes de que se complete una transacción DML:** Si una transacción falla y se revierte, cualquier evento publicado que tenga el comportamiento Publicar inmediatamente no se incluirá en el comportamiento de reversión.

- **Publicación de eventos en Flow para orquestar la automatización posterior:** La mejor forma de coordinar la lógica entre múltiples automatizaciones es utilizar [subflujos](https://developer.salesforce.com/docs/atlas.en-us.salesforce_vpm_implementation_guide.meta/salesforce_vpm_implementation_guide/vpm_designer_elements_subflow.htm) o [Flow Orchestrator](https://help.salesforce.com/s/articleView?id=sf.orchestrator_flow_orchestrator.htm).

- **Creación de dependencias de tiempo de ejecución:** No publique eventos para facilitar la comunicación entre paquetes sin realizar los [pasos](https://medium.com/salesforce-architects/5-anti-patterns-in-package-dependency-design-and-how-to-avoid-them-87bb50331cb8) apropiados para eliminar dependencias de tiempo de ejecución.

- **Cargas innecesariamente grandes:** Al realizar solicitudes, es mejor enviar y recibir la menor cantidad de datos posible en la carga. Cada acción de un usuario podría generar múltiples solicitudes, y es importante que se procesen de forma eficiente. El envío de más datos de los necesarios puede contribuir a ralentizar el transporte y aumentar el tiempo de procesamiento.

- **Gestión no selectiva de eventos de aplicación:** Cuando hay múltiples componentes escuchando un evento de aplicación, los desarrolladores deben asegurarse de que el controlador de eventos solo se ejecutará cuando sea realmente deseado y útil. Por ejemplo, en Lightning Console, los componentes contenidos en fichas que no están enfocadas pueden seguir escuchando aunque no sean visibles. Un desarrollador puede utilizar varias técnicas como el uso de un elemento de utilidad en segundo plano como el único oyente, o llamar a getEnclosingTabId() para determinar si esta instancia del componente está encerrada dentro de la ficha enfocada para garantizar que cada evento se gestiona solo cuando está pensado.

- **El uso de Eventos de plataforma publica un comportamiento incorrecto:** Los eventos de plataforma tienen dos comportamientos de publicación: Publicar inmediatamente y Publicar después de confirmar. Puede ser útil utilizar eventos de plataforma en tiempo real para casos de uso como Registro, donde desea publicar el evento de registro independientemente de si la transacción se realiza correctamente y se confirma. Sin embargo, utilice Publicar inmediatamente con mucho cuidado con eventos de plataforma en tiempo real. Los suscriptores pueden consumir eventos en la misma transacción y provocar bloqueos de filas u otras condiciones de carrera.

### Diseño de eventos efectivos

Al implementar una arquitectura dirigida por eventos, una de las claves del éxito es establecer estándares para el diseño de los eventos en sí. Las especificaciones variarán dependiendo de los casos de uso de su organización, pero estas son algunas directrices generales:

- **Determine la estructura óptima para sus cargas de eventos.** Aunque los tamaños de mensajes más pequeños reducen los tiempos de procesamiento, el bombardeo de suscriptores con volúmenes masivos de mensajes puede causar cuellos de botella de desempeño. Es posible que tenga que iterar en sus tamaños y estructuras de carga para encontrar el equilibrio correcto. MuleSoft y herramientas ESB similares proporcionan la capacidad de diseñar cargas personalizadas en los mensajes asociados con sus eventos, lo que puede ayudarle a visualizar estructuras de datos para mejorar el desempeño en el lado del suscriptor. (Consulte [Bien arquitectado - Gestión](/docs/architect/es-mx/well-architected/guide/composable#gestión-de-api) de API para obtener más información.)

- **Piense en sus procesos de extremo a extremo.** Asegúrese de no crear ningún escenario de "bucle infinito", que puede ser difícil de rastrear una vez que se implementen las integraciones. Un ejemplo de esto serían dos sistemas que publican eventos cuando se actualizan registros, mientras también escuchan los eventos del otro, lo que desencadena eventos publicados adicionales cuando se procesan.

  Puede solucionar este tipo de antipatrón agregando lógica a ambos sistemas que garantiza que los cambios realizados como resultado de un evento que se está consumiendo no dan como resultado la publicación de un nuevo evento. También debe asegurarse de documentar todos sus eventos, sus desencadenadores asociados y los sistemas descendentes que pueden verse afectados. Utilice esta documentación como referencia durante sesiones de diseño para ayudar a captar bucles interminables y escenarios similares lo antes posible. (Consulte [Bien arquitectado - Diseño](/docs/architect/es-mx/well-architected/guide/automated#diseño-de-procesos) de procesos para obtener más información.)

- **Utilice convenciones de nomenclatura comunes entre sistemas.** Las convenciones de nomenclatura coherentes son una mejor práctica para todo el desarrollo de software, incluyendo arquitecturas dirigidas por eventos. Tómese su tiempo para documentar un conjunto de estándares para nombres de eventos, estructuras, objetos asociados y procesos de gestión de errores para garantizar la coherencia entre sistemas. (Consulte [Estándares de diseño](/docs/architect/es-mx/well-architected/guide/intentional#estándares-de-diseño) bien diseñados para obtener más información.)

## Recursos

<table style="width:100%">
<thead>
<tr><th scope="col">Patrón</th><th scope="col">Recursos</th></tr>
</thead>
<tbody>
<tr><td>Publicar/Suscribir</td><td><a href="/docs/architect/es-mx/well-architected/guide/reliable#rendimiento">Salesforce Well-Architected: Rendimiento</a><br><a href="/docs/architect/es-mx/well-architected/guide/automated#gestión-de-datos">Salesforce Well-Architected: Gestión de datos</a><br><a href="/docs/architect/es-mx/well-architected/guide/composable#interoperabilidad">Salesforce Well-Architected - Interoperabilidad</a><br><a href="https://medium.com/salesforce-architects/achieve-architectural-efficiency-with-event-relays-c8d4ec7f07af">Publicación de blog: Alcanzar eficiencia arquitectónica con retransmisiones de eventos</a><br><a href="https://medium.com/salesforce-architects/announcing-pub-sub-api-generally-available-3980c9eaf0b7">Publicación de blog: Anuncio de API Pub/Sub disponible de forma general</a><br><a href="https://blogs.mulesoft.com/dev-guides/api-design/moving-from-restful-to-eventful/">Publicación de blog: Paso de RESTful a EVENTful</a><br><a href="https://blogs.mulesoft.com/dev-guides/event-driven-architectures-asyncapi/">Publicación de blog: Arquitecturas dirigidas por eventos y la especificación</a> AsyncAPI<br><a href="https://youtu.be/0WJjmmw1ryM">Video: Publicar / Suscribir presentación de patrón</a></td></tr>
<tr><td>Fanout</td><td><a href="https://developer.salesforce.com/blogs/2021/08/how-to-work-within-platform-events-delivery-limits">Publicación de blog: Cómo trabajar dentro de los límites de</a> entrega de eventos de plataforma<br><a href="https://youtu.be/zSncRUcucEU">Video: Presentación</a> de patrón de Fanout</td></tr>
<tr><td>Mensajes pasados</td><td><a href="https://youtu.be/U87nErhMuqw">Video: Presentación</a> de patrón de mensajes pasados</td></tr>
<tr><td>Transmisión</td><td><a href="https://medium.com/salesforce-architects/designing-for-high-volume-writes-in-salesforce-285689a08100">Publicación de blog: Diseño para escrituras de gran volumen en Salesforce</a><br><a href="https://youtu.be/-_1CDUI40fY">Video: Presentación de patrón de transmisión</a><br><a href="https://docs.mulesoft.com/mule-runtime/4.3/streaming-about">Documentación: Transmisión en aplicaciones Mule</a></td></tr>
<tr><td>Colocación en cola</td><td><a href="https://medium.com/salesforce-architects/designing-for-high-volume-writes-in-salesforce-285689a08100">Publicación de blog: Diseño para escrituras de gran volumen en Salesforce</a><br><a href="https://blogs.mulesoft.com/dev-guides/api-design/event-payment-apis/">Publicación de blog: Cómo diseñar arquitecturas de pago con API</a> con eventos<br><a href="https://youtu.be/jQvSKbMRbh0">Video: Presentación de</a> patrón de cola</td></tr>
</tbody>
</table>

<!-- document id=7fd4b41273423a10c11e157ca0140b2adf98d8f5041d07b17a1c6342f681c6b4 url=/architect/next/es-mx/decision-guides/guides/record-triggered.md -->

## Descripción general

Salesforce Platform ha avanzado continuamente en su arquitectura de automatización para satisfacer las demandas de procesos de negocio complejos. Las generaciones anteriores (Reglas de flujo de trabajo y Process Builder) proporcionaban los pasos iniciales en la lógica dirigida por eventos, ampliando las funciones de automatización para la lógica dirigida por eventos y ampliando el alcance a una gama más amplia de generadores.

Esta evolución ha culminado en una arquitectura consolidada de alto rendimiento centrada en dos pilares complementarios: Flujo desencadenado por registro y Desencadenadores de Apex. Este documento proporciona el marco y las directrices para tomar decisiones fundamentadas al diseñar automatizaciones de desencadenadores.

## Productos en ámbito

<table style="border:none">
  <tbody>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0">Flujo</td>
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://help.salesforce.com/s/articleView?id=platform.automate_about.htm&type=5">Salesforce Flow</a> es una potente herramienta de automatización de apuntar y hacer clic que permite a los usuarios crear procesos de negocio complejos, pantallas y lógica visualmente utilizando Flow Builder, sin redactar código. Automatiza tareas como actualizaciones de datos, envío de emails y orientación de usuarios, ofreciendo flexibilidad a través de tipos como Flujos de pantalla (interacción de usuario) y Flujos desencadenados (eventos de registro/programados).</td>
    </tr>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0">Apex</td> 
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm">Salesforce Apex</a> es un lenguaje de programación patentado y orientado a objetos para la plataforma Salesforce, similar a Java, que se utiliza para crear lógica de negocio personalizada, automatizar procesos y ampliar las funciones principales de CRM más allá de las herramientas declarativas.</td>
    </tr>
  </tbody>
</table>

## Comida para llevar

La creación de automatizaciones desencadenadas por registros ampliables, mantenibles y con desempeño en Salesforce Platform requiere un enfoque disciplinado dirigido por la arquitectura. La elección entre Flow y Apex, y la implementación de cada uno, se guía por un conjunto claro de principios. Estos puntos resumen estos principios y sirven como reglas fundamentales para el diseño de automatización moderno.

- **Seleccione la herramienta correcta para el trabajo en base a la densidad de automatización de objetos de Salesforce.**

  - Utilice Flujo desencadenado por registro para objetos de Salesforce para automatizaciones de **baja densidad**.

  - Aumente la lógica de flujo desencadenado por registro con Apex invocable para automatizaciones de **densidad media**.

  - Utilice desencadenadores Apex para objetos de Salesforce para automatizaciones de **alta densidad**.

- **Tenga cuidado al desencadenar procesos asíncronos.**  
  Esta regla se aplica independientemente de que esté invocando procesos asíncronos en un flujo desencadenado por registro o poniendo un trabajo colocable en cola desde Apex. Aunque este patrón puede ser tentador para descargar trabajo, puede introducir escenarios de gestión de errores complejos y aumentar el riesgo de alcanzar límites reguladores.

- **Utilice un punto de entrada por objeto de Salesforce.**  
  Para un objeto de Salesforce concreto, utilice un mecanismo como su punto de entrada en la automatización. Trate de evitar mezclar desencadenadores de Flujo y Apex como puntos de entrada para el mismo Objeto.

## Puntos de decisión

### Implementación declarativa frente a programática

Flow y Apex comparten un conjunto común de funciones fundamentales. Cada herramienta puede consultar registros, ejecutar lógica condicional, asignar variables y realizar operaciones DML como la creación, actualización y eliminación de registros, secuenciados para ejecutarse en un orden especificado.

Sin embargo, este solapamiento funcional no implica que las herramientas sean intercambiables. La elección arquitectónica no se trata de _si_ se puede realizar una tarea, sino de _cómo_ se realiza y cuáles son las implicaciones a largo plazo para el desempeño, la capacidad de ampliación y la capacidad de mantenimiento. Flujo destaca en claridad declarativa y velocidad de implementación para procesos sencillos, mientras Apex proporciona el control granular y la potencia bruta necesaria para soluciones complejas.

### Densidad de automatización

La **densidad de automatización** es la carga aplicada a un objeto específico de Salesforce. Sirve como una heurística para determinar la implementación óptima del objeto. A medida que crece la densidad de automatización, aumenta la probabilidad de infringir límites de transacciones.

Calcule la densidad de automatización inspeccionando tres dimensiones específicas de volumen y complejidad:

- **Cantidad de automatización:** El número sin procesar de entradas de metadatos de automatización exclusivas (flujos, acciones de desencadenador, etc.) que se ejecutan durante un único evento de Lenguaje de manipulación de datos (DML).

- **Volumen de registro:** Los registros por transacción procesados a través de cargas de API o procesamiento por lotes intenso, donde el desempeño se vuelve crítico.

- **Extensión de dependencia:** Una medición de las operaciones DML descendentes desencadenadas por la operación CRUD inicial. Cuantifica la profundidad del gráfico donde una actualización entra en cascada en actualizaciones en objetos relacionados (por ejemplo, caso → cuenta → contacto → acumulación personalizada).

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/automation-density.png" alt="Dimensiones de densidad de automatización">

A medida que crece el ámbito y la complejidad de su aplicación de Salesforce, confirme un único punto de entrada principal: Flujo desencadenado por registro o Desencadenadores de Apex. Evite particionar automatizaciones entre múltiples mecanismos en un único objeto de Salesforce, ya que lleva a una mala capacidad de mantenimiento y una gobernanza fragmentada.

### Matriz de selección de densidad

Utilice esta matriz para determinar el estándar arquitectónico requerido para su objeto de Salesforce.

- **Flujo desencadenado por registro** es la solución preferida para baja densidad de automatización. Ofrece un equilibrio de potencia y accesibilidad ideal para automatizaciones sencillas e independientes entre sí.

- **El patrón híbrido (Flujo desencadenado por registro con Apex invocable)** es una opción potente y mantenible para automatizaciones de densidad media con complejidad creciente. Este patrón permite a los equipos mantener la coreografía ordenada en Flujo declarativo mientras delegan operaciones con gran volumen de computación en Apex, equilibrando la accesibilidad con el desempeño.

- Los **desencadenadores Apex** proporcionan los elementos constructivos necesarios para una base arquitectónica sólida que admita automatizaciones de alta densidad. El desempeño, el control granular y la abstracción y el polimorfismo orientados a objetos de Apex son más adecuados para gestionar la complejidad y la escala de estos escenarios.

<table>
  <thead>
    <tr>
      <th scope="col" style="width:8%">Nivel de densidad</th>
      <th scope="col" style="width:18%">Cantidad de automatización</th>
      <th scope="col">Volumen de datos (Tamaño de lote)</th>
      <th scope="col">Extensión de dependencia</th>
      <th scope="col">Estándar arquitectónico</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Bajo</b></td>
      <td><b>&lt; 15</b><br>
        Automatizaciones</td>
      <td><b>Estándar</b><br>
        Interacciones de la interfaz de usuario dirigidas por el usuario o pequeñas cargas de API (1 a 200 registros)</td>
      <td><b>Discreta</b><br>
        Lógica autónoma. 0-1 operaciones DML descendentes en el mismo objeto o un objeto relacionado.</td>
      <td><b>Flujo desencadenado por registro</b></td>
    </tr>
    <tr>
      <td><b>Medio</b></td>
      <td><b>15–30</b><br>
        Automatizaciones</td>
      <td><b>Moderado</b><br>
        Procesamiento por lotes estándar (con lógica que requiere una masificación cuidadosa)</td>
      <td><b>Acoplado</b><br>
        Principal/Secundario actualiza de 2 a 4 operaciones DML descendentes. Riesgo de recurrencia</td>
      <td><b>Patrón híbrido</b><br>
        Flujo + Apex invocable</td>
    </tr>
    <tr>
      <td><b>Alto</b></td>
      <td><b>> 30</b><br>
        Automatizaciones</td>
      <td><b>Alto</b><br>
        Grandes volúmenes de datos con cargas de API masivas (2.000 a 10.000+ registros)</td>
      <td><b>Complejo y recursivo</b><br>
        Gráfico de dependencia profunda (5+ operaciones DML descendentes). Riesgo de bucles de recursión triangulares</td>
      <td><b>Marco de metadatos desencadenado por Apex</b></td>
    </tr>
  </tbody>
</table>
Las decisiones arquitectónicas del mundo real requieren que sopese todas las dimensiones de la densidad de automatización de forma colectiva. Tenga en cuenta el posible ámbito futuro al seleccionar un mecanismo de automatización para un objeto de Salesforce concreto.

Además, tenga en cuenta el número total diario de operaciones DML porque Salesforce aplica la gestión de recursos compartidos en un entorno de múltiples arrendatarios y [limita](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm) para evitar que las automatizaciones descontroladas monopolicen recursos compartidos. Los objetos de Salesforce con un gran volumen DML diario requieren una cuidadosa selección de automatización. Por ejemplo, los límites asíncronos de tiempo de CPU (60.000 ms) y tamaño de pila (12 MB) son superiores a los límites síncronos. Además, el límite de 24 horas de toda la organización en ejecuciones asíncronas (calculado como 250.000 o 200 veces sus licencias de usuario) requiere tener en cuenta el DML diario total en su diseño arquitectónico para evitar excepciones en tiempo de ejecución.

## Comparación de productos

Flujo desencadenado por registro es la principal herramienta declarativa de la plataforma para la automatización desencadenada por registro. La facilidad de uso de Flow y las salvaguardas de plataforma integradas permiten a los equipos crear fácilmente soluciones escalables y fiables. Es la opción ideal para la mayoría de equipos que crean soluciones en Salesforce Platform.

Apex es el lenguaje de programación patentado, fuertemente tipificado y orientado a objetos de la plataforma. Utilice Apex para objetos de Salesforce con alta densidad de automatización y para casos de uso que requieren alto desempeño, lógica sofisticada o control granular sobre transacciones.

Para ayudar en el proceso de toma de decisiones, esta matriz proporciona una comparación directa de Flujo y Apex entre funciones arquitectónicas clave.

<table>
  <thead>
    <tr>
      <th scope="col">Capacidad</th>
      <th scope="col">Flujo desencadenado por registro</th>
      <th scope="col">Desencadenador Apex</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Rápida entrega y mantenimiento</b></td>
      <td><b>Recomendado</b><br>
        La interfaz de usuario visual de Flow Builder permite a los administradores y otros generadores declarativos crear y modificar automatizaciones con mayor rapidez que redactar, probar e implementar código Apex. Esta interfaz potencia una gama más amplia de miembros del equipo para entregar valor de negocio y reduce la dependencia de recursos de desarrollador especializados para tareas sencillas.</td>
      <td><b>Requiere experiencia</b><br>
        Apex requiere desarrolladores de software debidamente cualificados para implementar, probar y mantener el código.</td>
    </tr>
    <tr>
      <td><b>Modularidad</b></td>
      <td><b>Disponible</b><br>
        Los flujos desencadenados por registros son modulares de forma predeterminada. En vez de lógica monolítica, los equipos crean flujos discretos para requisitos específicos y los coreografíen juntos utilizando el Explorador de desencadenadores de flujos. Esta modularidad permite una modificación aislada y una ampliación sencilla, reduciendo enormemente el costo de propiedad a largo plazo.</td>
      <td><b>Disponible</b><br>
        Apex está dividido en módulos funcionales por diseño. Cada clase Apex está pensada para implementar un único módulo de funciones.</td>
    </tr>
    <tr>
      <td><b>Visibilidad y gobernanza</b></td>
      <td><b>Recomendado</b><br>
        La naturaleza visual de Flujo proporciona una representación intuitiva de la lógica de negocio. El Explorador de desencadenadores de flujos proporciona una vista consolidada de todos los flujos en un objeto, facilitando a los arquitectos y administradores la tarea de comprender, gobernar y solucionar problemas sin leer código.</td>
      <td><b>Requiere experiencia</b><br>
        El uso de un marco de trabajo de metadatos para organizar desencadenadores es ventajoso, pero Apex requiere un equipo de desarrollo disciplinado para mantener el código organizado y mantenible.</td>
    </tr>
    <tr>
      <td><b>Procesamiento masivo de datos de alto desempeño</b></td>
      <td><b>No recomendado</b><br>
        Existe un riesgo elevado de alcanzar límites reguladores cuando se trata de lógica compleja o grandes volúmenes de datos.</td>
      <td><b>Recomendado</b><br>
        El código Apex se ejecuta más cerca de los servicios principales de la plataforma y ofrece a los desarrolladores un control mejorado sobre la optimización de consultas, el tratamiento de datos y la eficiencia algorítmica. Esto da como resultado un mejor desempeño y escala, especialmente en escenarios complejos que implican grandes volúmenes de datos.</td>
    </tr>
    <tr>
      <td><b>Lógica robusta y estructuras de datos</b></td>
      <td><b>Disponible</b><br>
        El <a href="https://help.salesforce.com/s/articleView?id=platform.flow_ref_elements_transform.htm&language=en_US&type=5">elemento Transformación de flujo</a> puede ayudar con algunas tareas de procesamiento complejas. Sin embargo, Flow carece de estructuras de datos de asignación y conjunto nativas, lo que hace que el procesamiento de datos complejo sea engorroso e ineficiente desde el punto de vista computacional.</td>
      <td><b>Recomendado</b><br>
        Apex proporciona acceso completo a Map, Set y bucles programáticos para una manipulación de datos altamente eficiente y segura. Como un lenguaje de programación completo, Apex también proporciona acceso a construcciones lógicas complejas, estructuras de datos y patrones de diseño que pueden ayudar a resolver problemas de negocio complejos de una manera mantenible y eficiente. Apex incluye una biblioteca estándar enriquecida de funciones avanzadas (por ejemplo, BusinessHours, Crypto) no disponible actualmente en herramientas declarativas.</td>
    </tr>
    <tr>
      <td><b>Control de transacciones</b></td>
      <td><b>No disponible</b><br>
        Flow no proporciona acceso a `Database.savepoint`, `Database.rollback` u operaciones DML parcialmente satisfactorias para confirmaciones o reversiones de transacciones parciales.</td>
      <td><b>Disponible</b><br>
        Apex proporciona un control completo y granular sobre la integridad de las transacciones y escenarios de recuperación de errores complejos.</td>
    </tr>
    <tr>
      <td><b>Distribución de email</b></td>
      <td><b>Recomendado</b><br>
        El envío de alertas de email preconfiguradas desde un flujo desencadenado por registro es sencillo y ampliable. Las alertas de email personalizadas se pueden crear y distribuir en tiempo de ejecución. Los emails personalizados están sujetos a <a href="https://help.salesforce.com/s/articleView?id=000381534&type=1">límites de envío</a> diarios.</td>
      <td><b>Disponible</b><br>
        Apex puede generar y enviar mensajes de email personalizados. Todos los emails enviados desde Apex están sujetos a los <a href="https://help.salesforce.com/s/articleView?id=000381534&type=1">límites de envío</a> diarios.</td>
    </tr>
    <tr>
      <td><b>Aplicación de salvaguardias de plataforma</b></td>
      <td><b>Recomendado</b><br>
        El flujo incluye protecciones integradas, como la masificación automática y los reintentos automáticos. Estas salvaguardas aumentan la velocidad de valorización y evitan riesgos de desempeño que requieren codificación manual compleja.</td>
      <td><b>Se requiere implementación manual</b><br>
        Las salvaguardias como el masificado deben codificarse de forma explícita (por ejemplo, gestionando recopilaciones y evitando SOQL dentro de bucles). Los reintentos automáticos no son nativos de desencadenadores y requieren lógica personalizada compleja para implementarse.</td>
    </tr>
    <tr>
      <td><b>Procesamiento asíncrono</b></td>
      <td><b>Disponible</b><br>
        Flow ofrece mecanismos sencillos para automatizaciones que requieren una transacción separada en una ruta asíncrona. Estas automatizaciones están sujetas a límites diarios.</td>
      <td><b>Disponible</b><br>
        Apex permite el control completo mediante Captura de datos de cambios y eventos colocables en cola gestionados por un suscriptor de desencadenador desvinculado.</td>
    </tr>
    <tr>
      <td><b>Procesamiento programado</b></td>
      <td><b>Recomendado</b><br>
        Las rutas programadas del flujo proporcionan una capacidad de programación única y potente (por ejemplo, "disparo 3 días antes de la fecha de cierre"). Esta función incluye la cancelación automática y la reprogramación si cambian los datos del registro. Estas automatizaciones están sujetas a límites diarios.</td>
      <td><b>No disponible</b><br>
        Un desencadenador Apex no puede programar de forma nativa un evento específico de registro temporal con cancelación automática. Aunque Apex programado existe, es un mecanismo fundamentalmente diferente que se ejecuta a una hora específica y no se programa durante el procesamiento de un registro individual como parte de un desencadenador.</td>
    </tr>
    <tr>
      <td><b>Ordenación y coreografía</b></td>
      <td><b>Disponible</b><br>
        El Explorador de desencadenadores de flujos permite a los administradores definir un orden de ejecución relativo para múltiples flujos en el mismo objeto.</td>
      <td><b>Disponible</b><br>
        Un marco de trabajo de desencadenador proporciona control granular sobre el orden exacto de las automatizaciones.</td>
    </tr>
    <tr>
      <td><b>Actualizaciones de campos del mismo registro</b></td>
      <td><b>Disponible (antes de guardar)</b><br>
        Flujo desencadenado por registro es la opción declarativa de mayor desempeño para actualizar el registro desencadenante antes de la confirmación DML inicial.</td>
      <td><b>Disponible (antes de guardar)</b><br>
        Apex proporciona la oferta de mayor desempeño con un gasto general mínimo.</td>
    </tr>
    <tr>
      <td><b>Crudo de objeto cruzado</b></td>
      <td><b>Disponible (después de guardar)</b><br>
        Flujo es adecuado para operaciones DML de objetos cruzados sencillas y de baja complejidad.</td>
      <td><b>Disponible (después de guardar)</b><br>
        Apex proporciona un control superior sobre la deduplicación, la gestión de errores y el desempeño para operaciones DML de objetos cruzados.</td>
    </tr>
    <tr>
      <td><b>Deduplicación de cálculos costosos</b></td>
      <td><b>Disponible</b><br>
        Flujo destaca en la eliminación de consultas redundantes y declaraciones DML a través de masificación automática. Sin embargo, el estado no se puede almacenar en caché o compartir entre diferentes desencadenadores de flujo o entre múltiples invocaciones del mismo flujo en una transacción. Esta limitación puede volverse importante en escenarios de desempeño extremo.</td>
      <td><b>Recomendado</b><br>
        Apex proporciona mecanismos para deduplicar operaciones costosas. Los desarrolladores pueden aprovechar el almacenamiento en caché de transacciones utilizando variables y propiedades estáticas, y el almacenamiento en caché a nivel de plataforma utilizando Caché de plataforma, para almacenar y reutilizar datos. Estas técnicas son importantes para reducir el consumo de límites reguladores de transacciones, como consultas SOQL, y garantizar un alto desempeño y capacidad de ampliación.</td>
    </tr>
    <tr>
      <td><b>Gestión de errores personalizados</b></td>
      <td><b>Disponible</b><br>
        El elemento CustomError puede bloquear una operación de guardado y mostrar un mensaje al usuario.</td>
      <td><b>Recomendado</b><br>
        El método <code>addError()</code> proporciona mensajería de error condicional y a nivel de campo flexible.</td>
    </tr>
  </tbody>
</table>

## Casos de uso

### Recomendaciones más ajustadas

Esta tabla proporciona recomendaciones generales "mejor ajustadas" para casos de uso generales, basándose en las funciones presentadas. En última instancia, tendrá en cuenta consideraciones adicionales para llegar a un mejor ajuste para sus escenarios particulares, como aquellos incluidos en la sección _Mejores prácticas relacionadas_ de este documento. Allí, aprenderá más sobre cuándo una combinación concreta de Flow y Apex proporciona el mejor enfoque.

<table>
  <thead>
    <tr>
      <th scope="col">Caso de uso</th>
      <th scope="col">Descripción</th>
      <th scope="col" style="width:16%">Mejor ajuste</th>
      <th scope="col" style="width:38%">Justificación</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Procesamiento por lotes de alto desempeño</b></td>
      <td>Cualquier automatización que debe procesar miles de registros de forma eficiente</td>
      <td>Apex</td>
      <td>Apex proporciona API enriquecidas para la interfaz con la plataforma y para la velocidad sin procesar.</td>
    </tr>
    <tr>
      <td><b>Procesamiento de datos complejo</b></td>
      <td>Escenarios que requieren manipulación de datos avanzada</td>
      <td>Apex</td>
      <td>Apex proporciona estructuras de datos, como Map y Set, que no están disponibles de forma nativa en Flow, y pueden ser críticas para redactar código de desempeño seguro y masivo.</td>
    </tr>
    <tr>
      <td><b>Control de transacciones</b></td>
      <td>Mecanismos de control como puntos de guardado, reversiones y confirmaciones parciales</td>
      <td>Apex</td>
      <td>Apex proporciona acceso a mecanismos como Database.savepoint y Database.rollback, y tiene la capacidad de procesar operaciones DML parcialmente satisfactorias.</td>
    </tr>
    <tr>
      <td><b>Sofisticada validación personalizada</b></td>
      <td>Validación de datos entre múltiples campos en un registro</td>
      <td>Apex</td>
      <td>Aunque Flujo puede evitar un guardado con el elemento `CustomError`, no está disponible en todos los tipos de flujo, incluyendo subflujos. El método Apex <code>addError()</code> proporciona múltiples mensajes de error específicos de campo que se pueden agregar a un registro en cualquier momento durante el procesamiento del desencadenador.</td>
    </tr>
    <tr>
      <td><b>Lógica moderadamente compleja en un proceso sencillo</b></td>
      <td>Manipulación de lógica y datos de complejidad moderada, simplificada por una biblioteca estándar de funciones avanzadas, que se produce como parte de un proceso sin complicaciones</td>
      <td>Flujo + Apex</td>
      <td>Flujo desencadenado por registro actúa como la capa de orquestación, mientras que las operaciones de alta complejidad están encapsuladas en Apex invocable.</td>
    </tr>
    <tr>
      <td><b>Lógica simple a moderadamente compleja</b></td>
      <td>Manipulación de datos de complejidad baja a moderada, con actualizaciones de desencadenador en los objetos de datos principales y relacionados</td>
      <td>Flujo</td>
      <td>Flujo es normalmente la opción a la que dirigirse, ya que se basa en un modelo declarativo que lo hace accesible tanto para administradores como desarrolladores.</td>
    </tr>
    <tr>
      <td><b>Notificaciones y mensajes salientes</b></td>
      <td>Envío de emails y mensajes salientes</td>
      <td>Flujo</td>
      <td>Flujo hace que el envío de alertas de email y mensajes salientes en cambios de registro sea sencillo y altamente escalable.</td>
    </tr>
    <tr>
      <td><b>Procesamiento programado</b></td>
      <td>Automatización en una fecha futura dinámica (por ejemplo, 3 días antes de una fecha de cierre)</td>
      <td>Flujo</td>
      <td>Las rutas programadas proporcionan una solidez única a Flujo, ya que la plataforma gestiona automáticamente la programación, cancelación y reprogramación de estas rutas si cambian los datos del registro.</td>
    </tr>
  </tbody>
</table>

### Procesamiento ampliable: Casos de uso asíncronos en profundidad

La capacidad de ampliación es una consideración crítica al diseñar su implementación. Cuando la lógica de negocio de una automatización desencadenada por registro se vuelve compleja, de larga ejecución o implica altos volúmenes de datos, los límites reguladores principales de la plataforma Salesforce se convierten en una restricción arquitectónica. Las operaciones como actualizaciones de datos masivas, llamadas de API complejas o cálculos pesados aumentan el riesgo de infringir límites, como el tiempo total de CPU o el número de declaraciones DML en una sola transacción de base de datos. Un fallo en un desencadenador síncrono debido a una excepción de límite hará que se revierta toda la transacción de guardado del usuario, dando como resultado una mala experiencia del usuario y una posible pérdida de datos. Este riesgo inherente exige un patrón arquitectónico para descargar trabajo complejo.

La automatización asíncrona se vuelve esencial en este caso. Utilizando mecanismos asíncronos, los arquitectos pueden desvincular de forma efectiva el trabajo de larga duración o gran volumen de la transacción de guardado de registros síncrona principal. Guarda completo de forma rápida y fiable, mientras que el procesamiento pesado se delega a una transacción gestionada por plataforma separada que se ejecuta más adelante. La desvinculación mejora la estabilidad, evita fallos de transacciones y es clave para crear aplicaciones de negocio ampliables. La plataforma ofrece varias herramientas especializadas para esto, cada una con distintos beneficios y ventajas en cuanto a fiabilidad, volumen y complejidad.

### Ruta asíncrona del flujo

La ruta Ejecutar de forma asíncrona en un flujo desencadenado por registro proporciona el mecanismo más sencillo para la lógica asíncrona "disparar y olvidar". Esta ruta se ejecuta en una transacción separada después de que la transacción de guardado de registros original se haya confirmado correctamente en la base de datos.

- **Caso de uso ideal**: Esto es adecuado para tareas que no requieren ejecución inmediata o tratamiento de errores personalizado. Algunos ejemplos incluyen el envío de una notificación por email, la creación de una tarea de seguimiento o la realización de una llamada sencilla a un sistema externo.

- **Limitaciones**: Este mecanismo comparte los mismos límites reguladores diarios que otras entrevistas de flujo asíncronas. No está diseñado para un procesamiento de gran volumen.

### Captura de datos de cambios (CDC)

Captura de datos de cambios (CDC) es un patrón de alto rendimiento, ampliable y resistente para gestionar lógica asíncrona desencadenada por un cambio de registro en escenarios de gran volumen. En este modelo, la única responsabilidad del desencadenador es guardar el registro de forma síncrona. A continuación, la plataforma publica un mensaje de evento detallado que contiene los cambios del registro en un bus de eventos de gran volumen. Un desencadenador Apex separado y exclusivo se suscribe a este evento de cambio. Realiza trabajos complejos, de larga duración o asíncronos.

- **Beneficio**: Este patrón desvincula el proceso asíncrono de la transacción de usuario inicial. Un fallo en el procesamiento asíncrono no provocará la reversión del guardado de registros del usuario. El patrón también proporciona una transmisión de eventos duradera que múltiples suscriptores internos o sistemas externos pueden consumir, y los eventos pueden reproducirse durante hasta 72 horas, proporcionando una fuerte resistencia.

- **Limitaciones**: Los mensajes de eventos de CDC no contienen el estado anterior del registro, el equivalente de un `Trigger.oldMap` Apex. La carga de evento incluye los nuevos valores de campo, pero no los valores desde los que cambiaron. Esto dificulta la implementación de lógica basada en una transición de estado específica (por ejemplo, ejecutar solo si `Status__c` cambió de "Pendiente" a "Aprobado"). Puede mitigar esto consultando el historial de campos del objeto en el suscriptor del evento, pero esto agrega complejidad al proceso y el seguimiento del historial de campos podría no estar disponible para el campo de interés específico. Esto puede limitar los tipos de automatización que puede descargar en los CDC.

De forma predeterminada, CDC se puede activar en un máximo de cinco objetos de Salesforce. Las organizaciones que requieren más pueden adquirir una licencia complementaria que elimina este límite y aumenta las asignaciones de entrega de eventos.

### Apex colocable en cola desde un desencadenador

Colocar un trabajo de Apex en cola directamente desde un desencadenador debe considerarse un patrón de riesgo, utilizado solo cuando se necesita el control proporcionado por Apex (por ejemplo, para lógica compleja o mecanismos de reintento personalizados), y CDC no es una opción viable.

Si se requiere Apex colocable en cola, la implementación debe incluir las salvaguardas apropiadas:

- **Limitar comprobaciones**: El código debe comprobar el número de trabajos ya en cola en la transacción antes de intentar agregar otro.

  ```
  if (Limits.getQueueableJobs() < Limits.getLimitQueueableJobs()) { ... }
  ```

- **Conciencia del contexto**: El código debe detectar si se está ejecutando en un contexto asíncrono, como un trabajo por lotes (`System.isBatch()`), y modificar su comportamiento para cumplir el límite más estricto de un trabajo por transacción en ese contexto.

### Limitar consideraciones para Apex asíncrono desencadenado

Invocar Apex asíncrono desde un desencadenador síncrono introduce riesgos de estabilidad. Para evitar la repercusión a nivel de organización (por ejemplo, superar límites), este patrón requiere un diseño y pruebas rigurosos.

- El límite diario para ejecuciones asíncronas de Apex (`Batch`, `Queueable`, `@Future`) se comparte en toda la organización (normalmente 250.000 o un cálculo basado en licencias de usuario). Una carga de datos masiva de 20.000 registros hará que se ejecute un desencadenador en partes de 200, dando como resultado 100 invocaciones de desencadenador separadas, incluso más si el tamaño de lote masivo es inferior a 200 registros. Si cada invocación pone en cola un trabajo asíncrono, se puede consumir una parte significativa del límite diario de una única carga de datos. Este consumo puede privar potencialmente a otros procesos de negocio críticos de recursos asíncronos.

- Los límites reguladores para los trabajos en cola son drásticamente diferentes dependiendo del contexto. Desde un desencadenador activado por una acción de usuario en la interfaz de usuario (una transacción _síncrona_), se pueden poner en cola hasta 50 trabajos colocables en cola. Sin embargo, desde un desencadenador activado dentro del método `execute` de una clase Apex por lotes (una transacción _asíncrona_), solo se puede poner en cola un trabajo colocable en cola. No tener en cuenta esta diferencia es un punto de fallo común y crítico, que lleva a errores de `LimitException` durante operaciones de datos de gran tamaño.

- Llamar Apex programable (`System.schedule`) o Apex por lotes (`Database.executeBatch`) directamente desde un contexto de desencadenador constituye un antipatrón. Estos métodos no están diseñados para invocarse desde contexto de desencadenador. Al hacerlo se producirá un consumo rápido de su asignación de Apex asíncrona, lo que dará como resultado excepciones de límite.

### Selección del patrón asíncrono correcto

Cada mecanismo asíncrono tiene ventajas específicas en cuanto al desempeño, los límites reguladores y la fiabilidad. Utilice este árbol de decisiones como guía para ayudarle a navegar por estas opciones y elegir el mecanismo correcto para su caso de uso.

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/async-pattern.png" alt="Árbol de decisiones de patrón asíncrono">

### La alternativa de trabajo programado

Como indica el gráfico de flujo, cuando se enfrenta a operaciones DML de gran volumen pero no puede utilizar Captura de datos de cambios (quizás debido a límites de objetos), la mejor opción arquitectónica es a menudo evitar un proceso invocado por desencadenador completamente.

En su lugar, considere utilizar un proceso programado. Este puede ser un Flujo programado o Apex programado. Los pasos requeridos son:

1. Realice una actualización sencilla y de bajo costo en el desencadenador síncrono. Por ejemplo, establezca un campo de `Status__c` en "procesamiento pendiente" o inserte un registro relacionado de bajo costo, como una publicación de Chatter, para indicar que el registro necesita procesamiento.

2. Cree un trabajo programado, ya sea un flujo programado o Apex programado, que se ejecuta periódicamente, como cada 15 minutos o cada hora.

3. Tenga la consulta de trabajo programada para todos los registros en el estado pendiente, ejecute la lógica compleja en un contexto controlado de gran volumen y luego actualice los registros como procesados.

Este patrón desvincula completamente el procesamiento pesado del guardado síncrono del usuario, no está sujeto al límite de un trabajo por transacción de un lote desencadenado y proporciona una solución altamente ampliable y gobernable para requisitos que no son en tiempo real.

Si la latencia de un trabajo programado no es aceptable para los requisitos de negocio y aún está restringido a utilizar CDC o una cola desencadenada, esto indica un desajuste arquitectónico significativo. En este punto, deben considerarse diferentes mecanismos. La reevaluación del diseño de la aplicación principal puede llevar a ciertas conclusiones, como:

- Adquisición del complemento para eliminar límites de objetos de CDC.

- Fundamentalmente, desafiar el requisito de negocio para determinar si el procesamiento casi en tiempo real es realmente una necesidad o si la latencia de un trabajo programado es una ventaja aceptable para la estabilidad de la plataforma.

## Consideraciones no funcionales

### Complejidad

El nivel de complejidad en una implementación forma parte del costo total de propiedad de una solución, así como su capacidad de adaptarse a los requisitos de negocio cambiantes. La complejidad puede afectar a cualquier implementación si no se siguen las mejores prácticas. En la sección _Mejores prácticas relacionadas_ de este documento, existen recomendaciones para reducir la cantidad de complejidad en su solución, incluyendo estos patrones:

- Patrón híbrido: Apex invocable para lógica compleja en flujo

- Uso de un marco de trabajo de metadatos para desencadenadores Apex

- Megaflujos frente a Flujos múltiples

### Procesos y estándares

La documentación es tan importante como la automatización en sí. No solo garantiza la capacidad de mantenimiento, también es clave para la IA y las herramientas basadas en agentes. La documentación le ayuda a comprender y gestionar sus procesos de negocio.

**En flujo**

- Establezca una convención de nomenclatura coherente para todos los elementos y variables.

- Utilice el campo Descripción para el flujo para explicar su propósito general, criterios de desencadenador y resultado previsto.

- Utilice el campo Descripción en cada elemento individual (por ejemplo, `Get Records`, `Action`, `Transform`). Esta práctica es la mejor forma de transmitir la intención. Es especialmente importante para acciones y subflujos invocables, donde la descripción es el lugar principal para explicar la lógica compleja realizada por la acción.

**En Apex**

- Comente su código claramente para explicar el _por qué_ detrás de su lógica, no solo el _qué_.

- Si utiliza un marco de trabajo dirigido por metadatos, asegúrese de que sus registros de metadatos incluyen y rellenan un campo Descripción legible para explicar qué hace cada clase de controlador y cuándo debe ejecutarse.

DevOps y el control de origen forman parte de un ciclo de vida de desarrollo maduro. Utilice siempre una herramienta de control de origen como Git para proyectos de Salesforce. Tanto las clases Apex como Salesforce Flows son metadatos que definen su lógica de negocio, y deben versionarse y gestionarse.

En el contexto de la gestión de automatizaciones desencadenadas por registros, una canalización de DevOps moderna proporciona beneficios esenciales.

- **Comprobaciones de calidad automatizadas:** Herramientas como [Salesforce Code Analyzer](https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/overview) se pueden configurar para ejecutarse automáticamente en sus oportunidades en curso. El análisis estático puede detectar patrones problemáticos en ambas herramientas de automatización antes de promocionarse, marcando problemas como elementos de `Get Records` ineficientes dentro de un bucle de flujo o consultas de `SOQL` dentro de un bucle de Apex for, que son causas comunes de degradación del desempeño.

- **Prevención de regresión:** A medida que crece su densidad de automatización, un cambio en una clase de Flujo o Apex puede tener consecuencias no deseadas para otras automatizaciones en el mismo objeto. Una estrategia de pruebas de DevOps sólida, donde las pruebas de Apex automatizadas se ejecutan contra cualquier cambio propuesto, es la forma más fiable de garantizar que una nueva versión de Flow no rompe la lógica Apex existente (y viceversa).

- **Colaboración y visibilidad:** El control de origen es la "fuente única de verdad". Permite a los administradores y desarrolladores trabajar en la automatización para el mismo objeto en paralelo. También proporciona un seguimiento de auditoría inestimable: cuando se interrumpe un proceso de producción, puede ver al instante _quién_ cambió la automatización, _cuándo_ la cambió y, a través de mensajes de confirmación, _por qué_ la cambió.

Para equipos con una combinación de administradores y desarrolladores, [DevOps Center](https://help.salesforce.com/s/articleView?id=platform.devops_center_overview.htm&type=5) proporciona una interfaz unificada para ayudar a coreografiar todos estos pasos, haciendo accesible un proceso de desarrollo escalable basado en el control de origen para todos los miembros del equipo.

Esta disciplina combinada de documentación y DevOps garantiza el estado y la capacidad de mantenimiento a largo plazo de su organización, lo que beneficiará a cada arquitecto y administrador que le siga.

## Mejores prácticas relacionadas

La guía de decisiones anterior se utiliza mejor antes de planificar su implementación. Está dirigido a ayudarle a elegir el mejor producto para sus casos de uso. Tras la selección del producto, es importante comprender las mejores prácticas existentes para su implementación.

### Explotar el patrón híbrido: Apex invocable para lógica compleja en flujo

El principio _Una herramienta por objeto_ es crítico para gestionar la automatización de alta densidad, pero no lo interprete como una opción binaria entre una pila puramente declarativa o programática. Un patrón arquitectónico más efectivo y mantenible aprovecha un modelo Híbrido: posicione Flujo desencadenado por registro como la capa de orquestación, mientras encapsula operaciones de alta complejidad en Apex invocable.

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/hybrid-pattern.png" alt="Diagrama de patrón híbrido">

#### La capa de orquestación: Flujo

Flujo desencadenado por registro sirve como la capa de orquestación para el proceso de negocio. Posee los criterios de entrada y el contexto de ejecución (el _qué_ y _el cuándo_). Al mantener la lógica de decisiones y el enrutamiento en esta capa, la topología de procesos de la arquitectura permanece transparente y gestionable a través del Explorador de desencadenadores de flujos, evitando que la lógica de negocio crítica se oculte en el código.

#### El componente Complejo: Apex invocable

Un ejemplo común de un componente complejo es la implementación de cálculos de Acuerdo de nivel de servicio (SLA) para registros Caso. Puesto que el objeto BusinessHours y su lógica relacionada (crítica para cálculos precisos que excluyen horarios no laborales y festivos) no es accesible de forma nativa en Flow, se utiliza una clase de Apex dedicada. Esta clase, a menudo denominada algo así como `ServiceLevelAgreementCalculator`, está diseñada con un único método estático, anotado con `@InvocableMethod`, para calcular el horario laboral transcurrido, determinar si el SLA está "Dentro del objetivo" o "Incumplido" y devolver un resultado estructurado. Este enfoque encapsula la lógica compleja y de alto desempeño en Apex permitiendo al mismo tiempo su ejecución e integración transparentes en la capa de orquestación declarativa de un flujo desencadenado por registro.

Una vez definida la clase de `ServiceLevelAgreementCalculator` Apex, está disponible para su uso en un flujo desencadenado por registro:

Este patrón demuestra una estricta separación de preocupaciones. La capa declarativa se utiliza para gestionar el ciclo de vida y la orquestación de transacciones mientras que el código se utiliza para la ejecución de alta complejidad. Al tratar el código como una utilidad funcional en vez de la base, equilibramos el desempeño y la capacidad de mantenimiento.

#### Ganancias clave con el patrón híbrido

**Modularidad**: La decisión se aleja de la singularidad de utilizar Apex o Flow para todo el proceso. En su lugar, la arquitectura encapsula lógica compleja en unidades discretas, seguras de forma masiva y comprobables de forma independiente. Estas unidades funcionan como componentes reutilizables consumidos por la capa declarativa, garantizando las escalas de automatización sin complicar el diseño arquitectónico.

**Reutilización**: La lógica está desvinculada del evento desencadenador. Una unidad de código bien diseñada (como un `InvocableMethod`) se escribe una vez pero se aprovecha en múltiples puntos de entrada: Flujos desencadenados por registro, flujos de pantalla o integraciones externas. Esta reutilización de código elimina el desarrollo redundante.

**Mantenibilidad**: La lógica de flujo de proceso permanece visible y gestionable en el Flujo declarativo. Esta centralización reduce drásticamente los gastos generales de depuración y garantiza que el orden de ejecución del sistema sea determinista y transparente.

#### Limitaciones y ventajas del patrón híbrido

Aunque el modelo híbrido de utilizar Apex invocable desde Flow es potente, no es un enfoque de talla única. Los arquitectos deben ser conscientes de las limitaciones y las ventajas específicas antes de comprometerse con una solución híbrida.

- **Sin asistencia antes de guardar**: Esta es la limitación más crítica. Las acciones invocables solo están disponibles en el contexto después del guardado (flujos para acciones y registros relacionados). No se pueden utilizar en el contexto de alto desempeño antes del guardado (flujos para actualizaciones de campo rápidas). Por lo tanto, este patrón no se puede utilizar para delegar actualizaciones de campos del mismo registro. Realice ese trabajo de alto desempeño utilizando elementos Flujo nativos en un flujo antes de guardar o dentro de un desencadenador Apex antes de contexto.

- **Sin compatibilidad después de la eliminación:** Flujo desencadenado por registro actualmente no admite el contexto posterior a la eliminación. Si un objeto de Salesforce tiene un requisito de negocio para ejecutar la automatización cuando se restaura un registro desde la papelera, un desencadenador Apex es la única solución.

- **Carga de desempeño en escenarios de gran volumen:** La transición del tiempo de ejecución de Flujo al tiempo de ejecución de Apex no es una operación de costo cero. Aunque generalmente es rápido, el acto de soltar en una acción invocable desde el tiempo de ejecución de Flow no es tan rápido como la ejecución nativa que permanece completamente dentro de un desencadenador Apex. Para la mayoría de las automatizaciones de densidad media, esta microcarga es una ventaja insignificante y valiosa para la accesibilidad aumentada. Sin embargo, para escenarios de alto desempeño y gran volumen extremos, un marco de trabajo solo de Apex puro tendrá una ventaja de velocidad de cálculo sin procesar.

### Estrategias para la automatización heredada

Aunque la heurística de densidad de automatización proporciona directrices definitivas para una arquitectura de campo nuevo más reciente, la realidad de los entornos de Salesforce de negocio suele ser más matizada. En organizaciones maduras, es común encontrar flujos desencadenados por registros y desencadenadores Apex operando en el mismo objeto de Salesforce. Este escenario es distinto del patrón híbrido explicado anteriormente: aquí, los flujos y desencadenadores Apex no están acoplados ni diseñados para funcionar juntos.

Esta coexistencia es a menudo el resultado de la evolución de las funciones de la plataforma o de deudas técnicas heredadas. Aunque este es un estado operativo tolerado, los arquitectos deben tratarlo como una compensación calculada en vez de un estado final.

La orquestación fragmentada causa una carga de trabajo de mantenimiento y regulación significativa, haciendo que las actividades de desarrollo, pruebas y gestión de incidentes sean inconexas y engorrosas. Esto lleva a un aumento del Tiempo de resolución (TTR) y la complejidad operativa.

- Para nuevos objetos de Salesforce, respete el principio de densidad de automatización como la guía principal.

- Para Objetos de Salesforce existentes con una huella híbrida y un desencadenador Apex dual y puntos de entrada de flujo desencadenados por registro, evalúe la densidad y luego cree arquitectos para refactorizar a un estado híbrido mantenible.

  - Para baja densidad, vuelva a factorizar desencadenadores Apex en flujos desencadenados por registros y especifique el orden de ejecución, llevándolos a un único punto de entrada de automatización.

  - Para densidad media, vuelva a factorizar megaflujos complejos en un subconjunto de flujos, con el orden de ejecución correcto. Introduzca desencadenadores Apex solo cuando sea absolutamente necesario, por ejemplo para dar cobertura después de cancelar la eliminación de contexto.

  - Para alta densidad, favor de implementar desencadenadores Apex.

### Uso de un marco de trabajo de metadatos para desencadenadores Apex

A medida que maduran los procesos de negocio de una organización en Salesforce Platform, el volumen y la complejidad de la automatización desencadenada por registros aumentan inevitablemente. Una mejor práctica fundamental es mantener _un desencadenador Apex por objeto de Salesforce_. Esta regla es crítica porque la plataforma no garantiza el orden de ejecución de múltiples desencadenadores en el mismo objeto para el mismo evento. Esta limitación puede llevar a comportamientos no deterministas, condiciones de raza y problemas difíciles de depurar.

Sin embargo, la adhesión al principio _de desencadenador único_ presenta un reto arquitectónico: cómo gestionar y orquestar toda la lógica de negocio invocada desde ese punto de entrada único de una forma ampliable y mantenible.

#### Las limitaciones de los controladores de desencadenadores Classic

La primera evolución de esta arquitectura fue el patrón Classic Trigger Handler. En este enfoque, el desencadenador Apex único delega toda su lógica a una clase de controlador correspondiente (por ejemplo, `OpportunityTriggerHandler`). Este método separa la lógica del archivo desencadenador y proporciona a los desarrolladores un control determinista sobre el orden de ejecución dentro de los métodos de la clase de controlador (por ejemplo, `afterInsert()`).

Aunque es una mejora, este patrón a menudo lleva a clases de controlador monolítico. Con el tiempo, a medida que se agregan más requisitos de negocio, la clase se vuelve grande, difícil de gestionar y difícil de probar de forma aislada. El orden de ejecución de todos los procesos individuales está codificado en un único método, lo que hace que la clase sea propensa a combinar conflictos, lo que aumenta drásticamente la regulación y los gastos generales de mantenimiento en un entorno de grandes compañías.

#### La solución: Un marco de trabajo de desencadenador dirigido por metadatos

Para resolver los problemas principales de modularidad y orquestación, los arquitectos cambian a un **Marco de trabajo** de desencadenador dirigido por metadatos. Este es un salto arquitectónico significativo que desvincula la lógica de automatización en sí de la configuración de _cómo_ y _cuándo_ se ejecuta.

Este marco se basa en tres ventajas clave:

- **Partición:** En vez de una única clase de gestor, la lógica de negocio principal se divide en clases de Apex atómicas pequeñas (por ejemplo, una clase de `RecalculateAccountValues` o una clase de `NotifySalesLeads`), respetando cada clase el _principio de responsabilidad_ única. Esta modularidad facilita la tarea de probar, depurar y comprender la lógica de forma aislada.

- **Orden y coreografía:** La orden de ejecución ya no está codificada en Apex. En su lugar, se define declarativamente por registros de configuración, normalmente almacenados en un tipo de metadatos personalizados (por ejemplo, `TriggerAction__mdt`). Esto permite a los administradores reordenar, agregar o eliminar acciones de automatización simplemente modificando un registro de metadatos, que no requiere una implementación o cambio de código.

- **Omitir funciones:** El marco de trabajo proporciona funciones de omisión granulares estandarizadas. Cada acción de automatización puede configurarse a través de su registro de metadatos para desactivarse de forma global o omitirse para usuarios administrativos específicos haciendo referencia a un permiso personalizado.

El desencadenador de Apex único para el objeto sirve solo como un despachador dinámico. No contiene lógica de negocio, pero en su lugar crea una instancia de una clase de `MetadataTriggerHandler` central. Este controlador consulta los registros de metadatos personalizados para determinar dinámicamente la secuencia de ejecución e invocar las clases Apex atómicas correctas en el orden prescrito. La automatización está unificada bajo una capa única, transparente y gobernable.

### Desduplicación de operaciones costosas en la transacción

Un beneficio importante de utilizar Apex en un marco de trabajo sólido es la capacidad de gestionar el estado de las transacciones y optimizar el desempeño eliminando el trabajo redundante. A medida que se acumula la lógica, es común que diferentes automatizaciones en la orden de guardado ejecuten de forma independiente las mismas operaciones costosas, consumiendo límites reguladores valiosos y aumentando el tiempo de operación DML.

El marco está diseñado para abordar esto con dos estrategias principales:

- **Gestión de estado compartido:** Dentro del ámbito de una única transacción Apex, las propiedades estáticas y las variables se aprovechan para almacenar en caché datos. Esto garantiza que una operación costosa, como una consulta de `SOQL` para un parámetro de configuración, solo se ejecute una vez, incluso si la lógica de automatización se invoca varias veces entre diferentes registros o fases del desencadenador. El consumo de límites de transacciones se reduce significativamente.

- **Utilización de caché de plataforma:** Para ir más allá del simple almacenamiento en caché intratransacción, utilice la caché de plataforma para evitar consultar la base de datos completa para ciertos datos. Esta caché en memoria gestionada es ideal para recuperar datos que no son primitivos, leídos frecuentemente en la base de códigos e inmutables en el transcurso de una transacción (por ejemplo, perfiles, funciones, horarios laborales). Utilizando la interfaz de `Cache.CacheBuilder`, el sistema comprueba la caché primero y solo realiza la consulta de la base de datos si los datos no están presentes, maximizando el desempeño y la capacidad de ampliación.

### Utilizar antes del guardado para actualizaciones del mismo registro

Utilice siempre una actualización antes del guardado cuando su automatización solo necesite cambiar valores de campo en el registro que inicia la transacción. Esto se aplica a actualizaciones de campo rápido en Flujo (que se ejecutan antes de guardar) y lógica antes de contexto en Desencadenadores Apex (antes de insertar, antes de actualizar).

Este patrón es de desempeño, independientemente de la herramienta que se utilice, porque evita una segunda operación DML y un ciclo de guardado recursivo. Los cambios se realizan en el registro en memoria _antes_ de que se confirme en la base de datos y se guardan como parte de la transacción original. Se elimina la sobrecarga de un segundo guardado, que de lo contrario volvería a ejecutar la orden de guardado completa e iniciaría toda la automatización de nuevo.

### Evitar la repetición no controlada

La recursión no controlada es un problema común en desencadenadores posteriores a la actualización, donde la lógica de un desencadenador realiza una actualización DML que a su vez provoca que el mismo desencadenador se active de nuevo. Esto crea un bucle infinito que termina finalmente con una excepción de límite regulador. Aunque históricamente se han utilizado indicadores booleanos estáticos o recopilaciones de Id. de registros procesados para evitar dicha repetición, un patrón más preciso y sólido es portar la lógica comparando valores de campo entre las versiones nueva y antigua del registro en sí.

Ejecute la lógica solo si un campo de interés específico cambió realmente. Esto evita que el desencadenador ejecute su lógica en operaciones DML posteriores en la misma transacción donde los datos críticos permanecen sin cambios.

#### Control de la recurrencia en flujos desencadenados por registros

En un flujo desencadenado por registro, evite la repetición no controlada estableciendo el flujo para ejecutarse solo cuando se actualiza el registro para cumplir los requisitos de condición:

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/recursion-flow.png" alt="Control de la recursión en flujo desencadenado por registro">

Si elige utilizar una fórmula de criterios de entrada en su flujo, puede evitar la repetición desbocada comparando la variable global de `$Record` (representando los nuevos valores) con la variable global de `$RecordPrior` (representando los valores originales antes del guardado). Por ejemplo, para asegurarse de que un flujo solo se ejecuta si el campo Importe en una oportunidad cambió, utilice esto en los criterios de entrada:

```
$Record.Amount != $Record__Prior.Amount
```

#### Control de la recurrencia en Apex

Compare valores de campo de la nueva versión del registro, `Trigger.new`, con los valores de campo de la versión antigua del registro, `Trigger.oldMap`, para ver si se produjo el cambio específico que está buscando. Este enfoque garantiza que la automatización sea idempotente y solo se ejecute cuando sea necesario, haciendo que el sistema sea más eficiente y evitando bucles recursivos catastróficos.

### Omitir la automatización

Una organización de Salesforce bien diseñada requiere un mecanismo coherente y fiable para omitir la automatización. Esta no es una función opcional, sino un requisito operativo principal para mantener la integridad de los datos y activar tareas administrativas.

Un marco de trabajo de omisión es esencial para algunos escenarios:

- Cuando se cargan grandes volúmenes de datos, la activación de desencadenadores para cada registro puede ralentizar drásticamente el proceso, provocar excepciones de límite y crear notificaciones y registros relacionados erróneos. Una omisión permite insertar los datos de forma limpia y eficiente.

- Un usuario de integración puede necesitar sincronizar datos desde un sistema de registro externo. La automatización que normalmente se desencadena para un cambio iniciado por el usuario (por ejemplo, el envío de un email, la creación de una tarea) puede ser indeseable o redundante cuando el cambio se origina desde otro sistema.

- Es posible que los administradores o el personal de asistencia necesiten realizar actualizaciones correctivas en registros. Un mecanismo de omisión les permite realizar estos cambios sin desencadenar la automatización de negocio estándar, lo que podría tener consecuencias no deseadas.

**Permisos personalizados**: El estándar moderno y ampliable para la implementación de la lógica de omisión son los permisos personalizados. Estos métodos son superiores a los antiguos por varias razones:

- **Flexibilidad:** Los permisos personalizados se pueden asignar a usuarios a través de conjuntos de permisos. Esta práctica se alinea con el modelo moderno de acceso y seguridad de Salesforce, permitiendo una asignación granular y flexible. Se puede otorgar una omisión a un usuario específico, o incluso temporalmente con una fecha/hora de caducidad específica.

- **Mantenibilidad:** El uso de permisos personalizados evita codificar perfiles o usuarios en lógica de automatización. Si la función de un usuario cambia o un nuevo perfil necesita omitir el acceso, el cambio es una asignación de Conjunto de permisos sencilla, no una modificación de flujo o código que requiere una implementación.

- **Escalabilidad:** Los permisos personalizados proporcionan un marco de trabajo ampliable para gestionar excepciones en una base de usuarios compleja. Se pueden asignar a usuarios a través de conjuntos de permisos, grupos de conjuntos de permisos o perfiles. Su asociación a un conjunto de permisos o perfil también es representable en metadatos de origen.

**Patrones de implementación**: Aplique un patrón de omisión coherente a todas las automatizaciones desencadenadas por registros en la organización.

**Omitir un flujo desencadenado por registro**: La forma más eficiente de omitir un flujo es evitar que se ejecute. Esto se logra agregando una condición a los criterios de entrada del flujo.

- En el elemento Inicio del flujo desencadenado por registro, establezca los Requisitos de condición en La fórmula se evalúa como Verdadero.

  - En el generador de fórmulas, incorpore una comprobación para el permiso personalizado utilizando la variable global `$Permission`. Combine la comprobación con sus criterios de entrada existentes.

    - Patrón de fórmula:

    ```
    ( ) && NOT($Permission.Bypass_This_Flow)
    ```

  - Este patrón garantiza que el flujo solo se ejecute si el usuario _no_ tiene el permiso personalizado especificado asignado. Esta comprobación se realiza incluso antes de que se cree la entrevista de flujo, lo que la convierte en el enfoque con mayor desempeño.

**Omitir un marco de trabajo desencadenador Apex**: En Apex, integre la lógica de omisión directamente en el marco de desencadenador dirigido por metadatos, permitiendo un control granular.

- El tipo de metadatos personalizados de `TriggerAction__mdt` debe incluir un campo de texto, por ejemplo, `BypassPermission__c`.

  - En la clase `MetadataTriggerHandler`, antes de ejecutar una acción de forma dinámica, el código debe leer el valor de este campo.

  - Si el campo se rellena, el controlador utiliza el método `FeatureManagement.checkPermission()` para determinar si el usuario que ejecuta actualmente tiene el permiso personalizado especificado.

  - Si `checkPermission()` devuelve true, el controlador omite esa acción específica y continúa con la siguiente en la secuencia.

  - Este patrón es potente porque permite una omisión global (si todos los registros de `TriggerAction__mdt` hacen referencia al mismo permiso) y una omisión granular por acción (si diferentes registros hacen referencia a diferentes permisos, o algunos no tienen ningún permiso de omisión).

### Megaflujos frente a Flujos múltiples

Es un antipatrón para consolidar toda la automatización de un objeto en un único flujo masivo. La consolidación en un flujo frente a la división de la lógica en múltiples flujos bien acondicionados no tiene un impacto importante en el desempeño. Las ganancias de desempeño más significativas provienen de:

- Uso de flujos antes de guardar para actualizaciones de campos del mismo registro.

- Redactar condiciones de entrada precisas para garantizar que los flujos no se ejecutan en cambios que no afectan a su caso de uso específico.

[Flow Trigger Explorer](https://trailhead.salesforce.com/content/learn/modules/record-triggered-flows/meet-flow-trigger-explorer) le permite asignar un valor de pedido a cada flujo en un objeto, garantizando un orden de ejecución secuencial.

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/trigger-explorer.png" alt="Explorador de desencadenadores de flujos">

## Recursos

<table>
  <thead>
    <tr>
      <th scope="col">Apex</th>
      <th scope="col">Flujo</th>
      <th scope="col">Operaciones</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>
        <ul>
          <li><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm">¿Qué es Apex?</a></li>
          <li><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_integration_intro.htm">Utilidades Apex</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.automate_about.htm&type=5">Acerca de la automatización con Salesforce Flow</a></li>
          <li><a href="https://trailhead.salesforce.com/content/learn/modules/record-triggered-flows/meet-flow-trigger-explorer">Conoce el Explorador de desencadenadores de flujos</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.flow_ref_elements_transform.htm&language=en_US&type=5">Elemento Transformación de flujo</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/guide/code-analyzer.html">Analizador de código de Salesforce</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.devops_center_overview.htm&type=5">DevOps Center</a></li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

<!-- document id=fedfaf7865fc65f365a49cfe5a2324fbec87d189656aeee04b0999a2d55fa923 url=/architect/next/es-mx/decision-guides/guides/get-started-integration-decision-guides.md -->

# Empezar a trabajar con guías de decisiones de integración

Esta sección proporciona directrices prácticas para elegir las herramientas y enfoques de integración de datos correctos para Salesforce. Cubre integraciones salientes, integraciones entrantes y escenarios entre organizaciones, ayudando a los arquitectos a diseñar e implementar integraciones de capa de datos que equilibran desempeño, capacidad de mantenimiento y costo.

---

## Integración de datos con Salesforce

La [integración de datos con Salesforce](/docs/architect/es-mx/decision-guides/guide/data-integration) proporciona una descripción general integral de las herramientas de integración de datos de Salesforce y las mejores prácticas:

- **Paisaje de herramientas de integración**: Descripción general de herramientas de integración de datos de Salesforce, incluyendo opciones de código bajo, híbridas y pro-código, con directrices sobre la selección de la herramienta correcta para casos de uso específicos.
- **Integraciones salientes**: Métodos para enviar datos desde Salesforce a sistemas externos, incluyendo Captura de datos de cambios, Servicios externos, Heroku Connect, Procedimientos de integración de OmniStudio, Salesforce Connect, MuleSoft Anypoint y soluciones Apex personalizadas.
- **Integraciones entrantes**: Enfoques para incorporar datos externos en Salesforce, con directrices sobre la replicación de datos frente a la virtualización y cuándo utilizar cada herramienta.
- **Integraciones entre organizaciones**: Métodos recomendados para compartir datos entre organizaciones de Salesforce, incluyendo MuleSoft Anypoint, Heroku Connect, API de Salesforce nativas, Captura de datos de cambios y Salesforce Connect con adaptador entre organizaciones, incluyendo directrices para sustituir implementaciones heredadas de Salesforce a Salesforce.
- **Marco de decisiones**: Consideraciones clave para seleccionar herramientas de integración, como herramientas existentes y panorama, requisitos de flujo de datos (temporización, direccionalidad, experiencia de usuario esperada), complejidad de implementación, capacidad de mantenimiento, volumen de datos y límites de plataforma.

Permite a los arquitectos elegir las herramientas y los patrones de integración correctos para cada escenario, minimizando la replicación de datos innecesaria, aprovechando las soluciones ESB/ETL existentes y garantizando integraciones ampliables y mantenibles que se alinean con los principios de la arquitectura de la compañía.

<!-- document id=a9d07745a2283d2b8ef9b0ff0c543b0d9c66494bac6160b87b3c6ff6a42bbd95 url=/architect/next/es-mx/decision-guides/guides/get-started-platform-decision-guides.md -->

# Empezar a trabajar con guías de decisiones de plataforma

Esta sección proporciona orientación práctica para tomar decisiones arquitectónicas críticas acerca de funciones de Salesforce Platform. Cubre el procesamiento asíncrono, los eventos desencadenados por registros, la creación de formularios, la arquitectura dirigida por eventos y los marcos de trabajo asíncronos basados en pasos para ayudar a los arquitectos a diseñar soluciones de plataforma ampliables, mantenibles y de alto desempeño.

---

## Procesamiento asíncrono

[Procesamiento asíncrono](/docs/architect/es-mx/decision-guides/guide/async-processing) proporciona directrices sobre herramientas y enfoques para operaciones asíncronas en Salesforce:

- **Herramientas de procesamiento asíncrono**: Comparación de Apex colocable en cola, Apex programado, Desencadenadores de eventos de plataforma, Captura de datos de cambios, Ruta programada (Flujos después de confirmar) y Ruta asíncrona (Flujos desencadenados por registro), con directrices sobre casos de uso apropiados.
- **Procesamiento asíncrono del lado del servidor**: Patrones para operaciones de base de datos de larga ejecución, llamadas externas y procesamiento de registros de gran volumen.
- **Procesamiento asíncrono del lado del cliente**: Técnicas como Llamadas de continuación Apex y procesamiento asíncrono del lado del cliente que se pueden ejecutar en navegadores o aplicaciones móviles.
- **Marco de decisiones**: Considere la validación de casos de uso, la capacidad de ampliación, la comprensión de cuándo las transacciones son verdaderamente asíncronas, el monitoreo y la gestión de eventos de carga extrema.
- **Mejores prácticas y antipatrones**: Directrices para un uso adecuado, incluyendo integraciones salientes, monitoreo y evitando riesgos comunes.

Permite a los arquitectos implementar patrones asíncronos ampliables, fiables y mantenibles, evitando riesgos que comprometen el desempeño.

---

## Formularios de construcción

[La creación de formularios](/docs/architect/es-mx/decision-guides/guide/build-forms) guía a los arquitectos sobre las opciones de creación de formularios de Salesforce:

- **Herramientas de creación de formularios**: Comparación de Formularios dinámicos, Flujo de pantalla, OmniStudio, Flujo de pantalla con componentes web Lightning (LWC) y LWC, incluyendo consideraciones de habilidades y licencias.
- **Marco de decisiones**: Tenga en cuenta la repercusión de los objetos, el ámbito de los formularios, la navegación, la ubicación (aplicación, móvil, web), el UX y la automatización de pruebas.
- **Orientación de selección**: de herramientas Recomendaciones desde formatos de registro sencillos a asistentes de múltiples páginas y formularios con marca de cara al cliente.
- **Patrones de combinación**: Directrices para combinar herramientas, por ejemplo, navegación de flujo de pantalla con estilo LWC.
- **Funciones avanzadas**: Profundice en funciones y limitaciones para informar la elección de herramientas.

Ayuda a los arquitectos a seleccionar el enfoque de creación de formularios correcto para sus requisitos específicos de UX, funcionales y de integración.

---

## Arquitectura dirigida por eventos

[Arquitectura dirigida por](/docs/architect/es-mx/decision-guides/guide/event-driven) eventos proporciona una guía integral de patrones y herramientas de eventos de Salesforce:

- **Herramientas de eventos**: Descripción general de eventos de plataforma, Captura de datos de cambios, API Pub/Sub, MuleSoft Anypoint, API de transmisión y consideraciones de integración.
- **Patrones dirigidos por eventos**: Incluye patrones de publicación/suscripción, fanout, mensajes pasados, transmisión y cola para varios casos de uso dirigidos por eventos.
- **Integración con MuleSoft**: Uso de conectores Anypoint (Pub/Sub, JMS, Kafka, Solace, MQ, MQTT, AMQP) para arquitecturas de negocio.
- **Eventos de plataforma y Captura de datos de cambios**: Directrices sobre mecanismos preferidos para publicar cambios de registro y campo, con migración desde PushTopic/Eventos genéricos.
- **Patrones de implementación**: Mejores prácticas para la capacidad de ampliación, la coherencia, la gestión de errores y el monitoreo.

Permite a los arquitectos diseñar sistemas escalables dirigidos por eventos casi en tiempo real que conectan múltiples sistemas de forma eficiente.

---

## Marco de trabajo asíncrono basado en pasos

[Marco asíncrono basado en](/docs/architect/es-mx/decision-guides/guide/step-based-async-framework) pasos proporciona un marco para el procesamiento de trabajos asíncronos modular y ampliable:

- **Arquitectura de marco**: Los componentes incluyen Apex colocable en cola, Finalizadores, Flujo programado, Cursores Apex, Acciones invocables e integraciones de Slack.
- **Procesamiento basado en pasos**: Divide el trabajo en pasos independientes que pueden ejecutarse, reintentarse y reiniciarse con una gobernanza compartida y visibilidad operativa.
- **Orientación de implementación**: Interfaz Patrones para paso, Procesador de pasos, Capa invocable Apex, gestión de retrasos y notificaciones.
- **Mejores prácticas**: Recomendado cuando la mayoría de la información existe en CRM, para cargas de trabajo de gran volumen y procesamiento de registros jerárquicos o basados en árboles; directrices sobre cuándo no utilizar.
- **Funciones de nivel de compañía**: Gobernanza, cumplimiento, estado distribuido, seguimiento de progreso, monitoreo de SLA, diagnóstico de fallos y registro a nivel de auditoría.

Proporciona a los arquitectos una alternativa ampliable a trabajos por lotes monolíticos y llamadas asíncronas encadenadas, admitiendo cargas de trabajo de Salesforce de gran volumen con transparencia operativa completa.

---

## Automatización desencadenada por registro

[Automatización desencadenada por](/docs/architect/es-mx/decision-guides/guide/record-triggered) registros proporciona el marco de trabajo para diseñar la automatización desencadenada por registros en Salesforce Platform:

- **Selección de herramientas**: Cuándo utilizar desencadenadores Flujo desencadenado por registro frente a Apex, guiados por la densidad de automatización (baja, media, alta) y la matriz de selección de densidad.
- **Densidad de automatización**: Cómo evaluar la cantidad de automatización, el volumen de registro y la expansión de la dependencia para elegir desencadenadores Flujo, híbrido (Flujo con Apex invocable) o Apex.
- **Puntos de entrada y gobernanza**: Un punto de entrada por objeto de Salesforce; directrices sobre condiciones de entrada, control de recursión y ejecución ordenada.
- **Invocación asíncrona**: Cuándo y cómo invocar procesos asíncronos desde flujos desencadenados por registros o Apex, con precaución sobre el tratamiento de errores y los límites reguladores.
- **Mejores prácticas**: Patrones para la masificación, el diseño híbrido de Apex y evitar riesgos comunes en la automatización de desencadenadores.

Permite a los arquitectos diseñar automatizaciones desencadenadas por registros ampliables, mantenibles y con desempeño alineadas con estándares de plataforma.

<!-- document id=8cfdec411fda5c758f0c904f0bf56d7fbcde58dbf274c9b189b71c8b09607b07 url=/architect/next/es-mx/decision-guides/guides/build-forms.md -->

## Descripción general de guía

¿Busca crear formularios en Salesforce Platform? Tiene múltiples opciones, que abarcan todo el continuo de código bajo a código profesional. Representando código bajo están Formularios dinámicos en Lightning App Builder y flujos de pantalla en Flow Builder. Pasar el rato en medio del continuo es la capacidad de ampliar flujos de pantalla con LWC y crear formularios de cara al cliente con OmniStudio. Además, representa el marco de trabajo LWC y su biblioteca de componentes base en constante crecimiento.

Las opciones son excelentes, pero ¿cómo determinar cuál (o qué combinación) es la opción correcta? Ahí es donde entra esta guía.

## Conclusiones clave

- **Conclusión #1: Al crear/modificar/ver formatos para páginas Lightning, utilice Formularios dinámicos.** Es posible que observe que faltan formatos de página en las tablas de comparación de esta guía. En adelante, la forma recomendada de configurar páginas de detalles de registros es utilizar Formularios dinámicos en Lightning App Builder. Consulte la sección sobre [Formatos de página](#formatos-de-página) para obtener más información acerca de por qué no esperamos mejorarlos aún más.
- **Conclusión #2: Si necesita crear o modificar un formulario para exactamente un objeto, comience con páginas Lightning y Formularios dinámicos.** Esta es la forma más sencilla de crear formularios en Salesforce Platform. También proporciona algunas funciones adicionales, como la capacidad de controlar la visibilidad del campo. Si sus requisitos son más avanzados, siga leyendo. Flujo de pantalla, OmniStudio o Componentes web Lightning (LWC) podrían ajustarse mejor.
- **Conclusión #3: Si está creando un formulario de varias páginas o un asistente y no tiene requisitos estrictos de marca o UX, comience con un Flujo de pantalla.** Los flujos de pantalla proporcionan un marco de trabajo de navegación lineal para orquestar múltiples formularios juntos. Podría utilizar LWC para crear su propio marco de trabajo para navegar entre formularios, pero recomendamos dejar que Flow haga el trabajo duro por usted, de modo que pueda centrarse en los formularios en sí en vez de preocuparse por el [estado del formulario](/docs/architect/es-mx/well-architected/guide/engaging#formularios).
- **Conclusión #4: Si necesita lógica o acciones adicionales _detrás del formulario_, utilice un Flujo de pantalla, OmniStudio o LWC.** Las tres herramientas ofrecen formas para que su solución haga más que crear o modificar un único registro. Ese “más” podría ser una lógica más avanzada, como la bifurcación o la iteración, o podrían ser más acciones como la integración con sistemas externos, el envío de emails o el envío de notificaciones a la aplicación móvil de un usuario.
- **Conclusión #5: ¿Tiene requisitos de UX sofisticados? ¿Necesita gestionar dinámicamente algo más que visibilidad? Utilice LWC u OmniScript.** Si sus requisitos se pueden alcanzar con formatos basados en columnas y temas sencillos, puede crear sus formularios directamente en un generador de código bajo. Para un control más preciso sobre el estilo de su formulario, necesitará la flexibilidad definitiva de LWC. Si es un cliente de Industries y necesita una marca de píxeles perfecta o tiene datos jerárquicos complejos, utilice OmniStudio, que le permitirá crear formularios de categoría de consumidor que pueden gestionar transformaciones de datos y lógica de negocio complejas.
- **Conclusión #6: Si necesita automatización de pruebas, comience con Componentes web Lightning.** Puede redactar pruebas de unidad para cualquier LWC, independientemente de dónde tenga intención de incrustarlo. Esto le proporciona la capacidad de crear una estrategia de prueba más sólida, que puede incluir pruebas masivas con múltiples registros y pruebas negativas. [Consulte Salesforce Well-Architected - Testing Strategy](/docs/architect/es-mx/well-architected/guide/resilient#estrategia-de-prueba) para obtener más información acerca de la creación de pruebas que le ayudarán a ver cuán bien se alinearán sus formularios con sus requisitos funcionales y no funcionales.

Tenga en cuenta que su elección no tiene que ser una opción o puede combinar el poder de múltiples opciones. Por ejemplo, si necesita el sistema de navegación integrado de Flow y la flexibilidad de estilo completa que ofrece LWC, utilícelos conjuntamente.

## Herramientas para crear formularios con Salesforce

La tabla siguiente describe las herramientas disponibles para la creación de formularios con Salesforce, junto con sus habilidades requeridas y consideraciones de licencia. Más adelante profundizaremos en las funciones específicas compatibles con cada herramienta, así como en cómo elegir entre herramientas basadas en clics y herramientas basadas en código (y cuándo combinarlas):

<table>
  <colgroup>
    <col span="1" style="width: 40%;">
    <col span="1" style="width: 30%;">
    <col span="1" style="width: 30%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Habilidades requeridas</th>
      <th scope="col">Requisitos de licencia adicionales</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Formularios dinámicos</b></td>
      <td>Código bajo</td>
      <td>No</td>
    </tr>
    <tr>
      <td><b>Flujo de pantalla</b></td>
      <td>Código bajo</td>
      <td>No</td>
    </tr>
    <tr>
      <td><b>OmniStudio</b></td>
      <td>Código bajo + Código profesional</td>
      <td>Requiere paquete Industries</td>
    </tr>
    <tr>
      <td><b>Flujo de pantalla + Componentes web Lightning</b></td>
      <td>Código bajo + Código profesional</td>
      <td>No</td>
    </tr>
    <tr>
      <td><b>Componentes web Lightning</b></td>
      <td>Código Pro</td>
      <td>No</td>
    </tr>
  </tbody>
</table>

## Puntos de decisión de un vistazo

La tabla siguiente contiene una descripción general de los puntos de decisión en los que debe pensar al realizar sus selecciones de productos, junto con preguntas que debe hacerse acerca de cada uno. Profundizaremos más en cada uno de estos temas a lo largo del resto de esta guía.

<table>
  <colgroup>
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 75%;">
  </colgroup>
  <tbody>
    <tr>
      <td><b>Repercusión de objeto</b></td>
      <td>Determine si su formulario operará contra un único objeto o necesita operar contra múltiples objetos.</td>
    </tr>
    <tr>
      <td><b>Ámbito de formulario y navegación</b></td>
      <td>Determine si todos los campos de su formulario se ajustarán lógicamente a una única pantalla o si los usuarios deben poder navegar entre múltiples pantallas.</td>
    </tr>
    <tr>
      <td><b>Ubicación</b></td>
      <td>Identifique la(s) ubicación(es) donde desea incrustar el formulario, que puede ir desde algún lugar dentro de una aplicación de Salesforce a una aplicación móvil o incluso un sitio web externo.</td>
    </tr>
    <tr>
      <td><b>Controlador</b></td>
      <td>Identifique las acciones o la lógica que se deben realizar en segundo plano mientras los usuarios interactúan con su formulario, incluyendo transformaciones de datos e integraciones con sistemas externos.</td>
    </tr>
    <tr>
      <td><b>Validation</b></td>
      <td>Determine si tiene o no requisitos de validación de entrada adicionales que vayan más allá de la validación a nivel del sistema estándar proporcionada por Salesforce.</td>
    </tr>
    <tr>
      <td><b>Seguridad</b></td>
      <td>Determine si su formulario debe comprobar el acceso del usuario antes de realizar ciertas operaciones, si desea controlar quién puede acceder al formulario y si desea controlar dónde se puede incrustar el formulario.</td>
    </tr>
    <tr>
      <td><b>Diseño de interacciones</b></td>
      <td>Identifique los tipos de interacciones o condiciones que deben desencadenar respuestas dinámicas en su formulario.</td>
    </tr>
    <tr>
      <td><b>Estilo</b></td>
      <td>Determine el nivel de sofisticación para su estilo y CSS deseados.</td>
    </tr>
    <tr>
      <td><b>Formato</b></td>
      <td>Identifique los requisitos de formato de su formulario en términos del número requerido de columnas, fichas, acordeones y la capacidad de mostrar bloques de datos repetitivos.</td>
    </tr>
    <tr>
      <td><b>Traducción</b></td>
      <td>Determine si su formulario tendrá que traducirse a otros idiomas.</td>
    </tr>
    <tr>
      <td><b>Automatización de pruebas de interfaz</b> de usuario</td>
      <td>Determine si sus procesos de DevOps requerirán que su formulario se someta a pruebas de unidad automatizadas o pruebas de extremo a extremo automatizadas</td>
    </tr>
    <tr>
      <td><b>Métricas</b></td>
      <td>Identifique las formas en que le gustaría realizar un seguimiento del uso de su formulario, incluyendo vistas de página, cantidad de tiempo empleado en el formulario, índices de realización y índices de éxito</td>
    </tr>
    <tr>
      <td><b>Empaquetado e implementación</b></td>
      <td>Determine cómo desea distribuir o implementar su formulario después de su creación.</td>
    </tr>
  </tbody>
</table>

Estos son los términos que utilizamos en las tablas de comparación junto con sus definiciones:

- **Disponible:** Funciona bien con consideraciones básicas.
- **No es ideal:** Puede funcionar pero no es la herramienta óptima.
- **Hoja de ruta:** Apoyo estimado en los próximos doce meses (junio de 2025).
- **Futuro**: Estimado para asistencia más allá de los próximos doce meses.
- **No disponible:** No hay planes para admitir esta función en los próximos doce meses.

## Presentaciones de puntos de decisión

Como se prometió, comencemos a profundizar en una variedad de puntos de comparación y diferencias funcionales entre Formularios dinámicos, Flujos de pantalla, OmniStudio, Flujos de pantalla con LWC integrados y el marco de trabajo de LWC en sí.

### Impacto de objeto

Si su formulario funciona con un único objeto de Salesforce, cualquiera de las herramientas que estamos comparando funcionará. Las cosas se complican un poco con formularios de objetos cruzados o que distinguen entre objetos. Por objetos específicos, nos referimos a entradas que no se asignan a ningún objeto de Salesforce. Quizás su formulario represente una estructura de datos que enviará a un servicio externo, como Stripe o DocuSign. O quizás está utilizando varias entradas en su formulario para calcular un valor y luego confirmar ese valor en la base de datos.

#### Preguntas para formular:

- ¿Contra qué objetos operará el formulario?
- ¿Es solo un objeto o hay varios objetos?
- ¿Está trabajando con objetos específicos (por ejemplo, Cuenta, Contacto, Oportunidad, Prospecto y Caso) o su formulario también tendrá que funcionar con otros objetos?

<table>
  <colgroup>
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Objeto único</th>
      <th scope="col">Objeto cruzado</th>
      <th scope="col">Agnóstico de objetos</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Formularios dinámicos</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td>No disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla + LWC</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
  </tbody>
</table>

Tanto para formularios de objetos cruzados como de objetos específicos, Flow y OmniStudio son opciones sólidas. Los componentes disponibles en pantallas de flujo son agnósticos por naturaleza, de modo que puede elegir qué hacer con esos datos en segundo plano. Por ejemplo, utilice los datos ingresados en un formulario para crear múltiples registros en segundo plano, o utilice los datos para realizar otras acciones como generar publicaciones Chatter, enviar mensajes de Slack, enviar emails o conectar con servicios externos.

Para casos sencillos, el uso de componentes LWC existentes, como Lightning, puede ser una forma sencilla de reducir el código necesario para proporcionar una solución sólida. Sin embargo, para escenarios donde están involucrados múltiples objetos, Flow proporciona un control integral para todos los objetos y elimina la necesidad de que los desarrolladores atraviesen relaciones y dependencias complejas.

OmniStudio lleva las cosas un paso más allá y es completamente consciente de los objetos: separa el formulario que ve un usuario del modelo de datos subyacente. En su lugar, OmniStudio manipula el JSON subyacente que luego se asigna a objetos de Salesforce (o datos externos) utilizando herramientas como [Asignador de datos](https://help.salesforce.com/s/articleView?id=sf.os_dataraptors.htm&type=5) y [Procedimientos de integración](https://help.salesforce.com/s/articleView?id=sf.os_omnistudio_integration_procedures_48334.htm&type=5). Asignador de datos y Procedimientos de integración son dos componentes clave en la conexión de sus formularios de OmniStudio con datos internos y externos a Salesforce. Utilizando elementos de arrastrar y soltar, puede trabajar con datos jerárquicos complejos en un sistema externo y luego transformar los datos para ajustarse a sus necesidades dependiendo de dónde necesitan ir los datos. También le permiten utilizar fórmulas para realizar operaciones matemáticas y lógicas en matrices o listas de datos, como Apex.

[<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-objectimpactnoheader.png" alt="Integraciones de OmniStudio">_Integraciones de OmniStudio_](/docs/architect/es-mx/reference-diagrams/guide/omnistudio-integrations)

### Ámbito y navegación de formularios

Si puede obtener todas sus entradas de usuario desde un formulario de pantalla única, comience con Formularios dinámicos. Sin embargo, aunque Formularios dinámicos en páginas de registro puede utilizar la función Ruta para representar libremente las diversas etapas en su proceso de negocio, es posible que no se ajuste a la mayoría de sus casos de uso.

#### Preguntas para formular:

- ¿Necesita una sola pantalla o el usuario tendrá que navegar entre múltiples pantallas para completar una tarea?
- ¿Desea que sus usuarios vean una representación visual de lo avanzado que están en el proceso de rellenar su formulario?
- ¿Se requerirá a sus usuarios rellenar la información en cada pantalla en un orden específico o deben poder moverse de un lado a otro entre pantallas según sea necesario?

<table>
  <colgroup>
    <col span="1" style="width: 20%;">
    <col span="1" style="width: 20%;">
    <col span="1" style="width: 20%;">
    <col span="1" style="width: 20%;">
    <col span="1" style="width: 20%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Pantalla única</th>
      <th scope="col">Formulario de múltiples pantallas</th>
      <th scope="col">Indicadores de progreso</th>
      <th scope="col">Saltar la navegación entre pasos / pantallas</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Formularios dinámicos</th>
      <td class="guide-table-ok">Disponible</td>
      <td>No disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td>No disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td>No disponible</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla + LWC</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-no">No es ideal</td>
      <td class="guide-table-no">No es ideal</td>
      <td class="guide-table-no">No es ideal</td>
    </tr>
  </tbody>
</table>

Si necesita más funciones de las que ofrece Formularios dinámicos, la elección entre Flow, OmniStudio y LWC dependerá también de otras preguntas:

- ¿Qué habilidades tiene su equipo? Para una organización más cargada de administradores, recomendamos comenzar con Flujo. Si tiene soluciones de Industries, su equipo ya está familiarizado con OmniStudio y su proyecto tiene requisitos de UX estrictos, comience con OmniStudio.
- ¿Está bien mostrar una barra de navegación en la parte inferior de su formulario? Si el flujo de pantalla y la experiencia de navegación de OmniScript no son deseables, inclínese hacia LWC.
- ¿Qué debe suceder detrás del formulario? Si necesita que un administrador pueda configurar el comportamiento, cree un flujo o, para cambios básicos como el cambio de etiquetas de campo, un OmniScript. De lo contrario, para relaciones complejas de múltiples objetos, cree un OmniScript o LWC.
- Si elige Flow u OmniStudio, es posible que tenga que crear un LWC de todos modos para alcanzar la UX correcta. Si ya está creando un LWC para diseñar su formulario correctamente, considere si [integrar ese componente en un flujo](https://developer.salesforce.com/docs/platform/lwc/guide/use-flow-embed-component.html) es excesivo.

Si, por el contrario, su solución tiene el aspecto de un asistente, donde el usuario navega entre múltiples pantallas, considere Flow u OmniStudio. Flujos y OmniStudio incluyen un modelo de navegación integrado, de modo que no tiene que crear y mantener LWC que están encadenados juntos. La navegación es lineal, con acciones de avance, acciones de retroceso y un mecanismo para guardar el formulario para más adelante. También puede crear un formulario con navegación no lineal si se ajusta a sus fines. Para obtener un excelente ejemplo de ello utilizando flujos de pantalla, consulte el paquete [Auditoría de establecimiento digital](https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3A00000FMkOtUAL) de Salesforce Labs.

OmniStudio ofrece una ventaja de navegación clave proporcionando indicadores de progreso desde la navegación estándar que aflora “pasos” en el formulario. Esta vista de paso muestra automáticamente dónde está un usuario en un formulario de múltiples pasos concreto. A diferencia de Flujo, permite a los usuarios ‘saltar’ entre pantallas haciendo clic en varios pasos del formulario.

Independientemente de si está creando formularios de pantalla única o múltiples pantallas, asegúrese de que sus formularios están [simplificados](/docs/architect/es-mx/well-architected/guide/engaging#formularios) de modo que sea fácil para sus usuarios navegar.

### Ubicación

Si está incrustando un formulario en una página de registro Lightning estándar, cualquiera de las herramientas que estamos comparando funcionará, con la advertencia de que Formularios dinámicos solo está disponible en estos momentos en el escritorio. Sin embargo, si está buscando proporcionar una experiencia que permita a los usuarios acceder a formularios desde otras ubicaciones, es posible que tenga que considerar opciones alternativas.

#### Preguntas para formular:

- ¿Necesitarán los usuarios acceder al formulario a través de escritorio, móvil o ambos?
- ¿Deberían los usuarios poder acceder al formulario desde cualquier parte de su aplicación a través de una barra de utilidades?
- ¿Desea utilizar acciones rápidas para que los usuarios puedan rellenar su formulario sin tener que abandonar la página en la que se encuentran actualmente?
- ¿Necesita su formulario estar disponible en un sitio web externo?

<table>
  <colgroup>
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
    <col span="1" style="width: 7.14%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Página de registro Lightning</th>
      <th scope="col">Página de inicio o página de aplicación Lightning</th>
      <th scope="col">Sitios de Aura Experience Cloud</th>
      <th scope="col">Sitios de LWR Experience Cloud</th>
      <th scope="col">Snap integrados</th>
      <th scope="col">Barra de utilidades</th>
      <th scope="col">Acción específica de objeto</th>
      <th scope="col">Acción global</th>
      <th scope="col">Aplicación móvil Salesforce**</th>
      <th scope="col">Field Service Mobile</th>
      <th scope="col">SDK móvil</th>
      <th scope="col">Sitios y aplicaciones externos</th>
      <th scope="col">LWC personalizado</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Formularios dinámicos</th>
      <td class="guide-table-ok">Disponible</td>
      <td>No disponible</td>
      <td>No disponible</td>
      <td>No disponible</td>
      <td>No disponible</td>
      <td>No disponible</td>
      <td>No disponible</td>
      <td>No disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td>No disponible</td>
      <td>No disponible</td>
      <td>No disponible</td>
      <td>No disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-roadmap">Roadmap</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible***</td>
      <td>No disponible</td>
      <td class="guide-table-roadmap">Roadmap</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td>No disponible</td>
      <td>No disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td>No disponible</td>
      <td>No disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td>No disponible</td>
      <td>No disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla + LWC</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-roadmap">Roadmap</td>
      <td class="guide-table-ok">Disponible</td>
      <td>No disponible</td>
      <td>No disponible</td>
      <td class="guide-table-no">No es ideal</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-roadmap">Roadmap</td>
      <td class="guide-table-roadmap">Roadmap</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-roadmap">Roadmap</td>
      <td class="guide-table-roadmap">Roadmap</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <td colspan="14">*Los flujos se pueden integrar en sitios de Experience Cloud LWR pero tienen consideraciones que debe tener en cuenta.<br>**Los flujos y los LWC son compatibles con la aplicación móvil Salesforce, pero la aplicación móvil Salesforce no es compatible con todas las formas en que puede incrustar flujos y LWC. Por ejemplo, las acciones específicas de objetos son compatibles en dispositivos móviles, pero los elementos de la barra de utilidades no.<br>***La aplicación Field Service Mobile no admite muchas de las funciones de flujo más recientes, ya que está diseñada desde un Motor de flujos antiguo y Tiempo de ejecución de flujo de pantalla: tiene modificaciones especiales para que funcione sin conexión.</td>
    </tr>
  </tbody>
</table>

Puesto que requieren contexto de registro, Formularios dinámicos solo se admiten en páginas de registro Lightning. Sin embargo, Formularios dinámicos no es compatible en páginas de Experience Cloud. Esta limitación está vigente porque Experience Cloud no utiliza el marco de trabajo subyacente del que dependen Formularios dinámicos: Páginas Lightning. Estamos evaluando esto basándose en solicitudes de Formularios dinámicos en Experience Cloud.

Puede crear flujos que requieren un contexto de registro o flujos que funcionan de forma global. Como tal, puede incrustar flujos en una variedad de ubicaciones. Para flujos contextuales de registro, puede ser una página de registro Lightning, una página de registro de Experience Cloud, una acción específica de objeto o una implementación de Acciones y recomendaciones. Para el flujo global, esa podría ser la barra de utilidades, otras páginas Lightning o Experience Builder, un Snap o una aplicación externa. Los flujos no se admiten actualmente como acciones globales, pero como solución puede incluir el flujo en un componente Aura.

OmniStudio le permite crear FlexCards y OmniScripts componibles que puede colocar casi en cualquier lugar donde pueda poner un flujo. Sin embargo, aunque son componibles, no lo son.

LWC admite un alto grado de reutilización, ya que está creando componentes que se pueden asociar con destinos a través de metadatos en Salesforce, Comunidades e incluso en proyectos de código abierto. Los componentes LWC también se pueden integrar en su propio sitio web a través de [Lightning Out](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lightning_out).

[<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-locationnoheader.png" alt="Lightning Out en sitios externos">_ Lightning Out en sitios externos_](/docs/architect/es-mx/reference-diagrams/guide/lightning-out-on-external-sites)

Los componentes web Lightning no se admiten actualmente como acciones rápidas (específicas de objetos o globales), pero como solución puede incluir un LWC en un componente Aura (como puede hacer con flujos). Los componentes LWC también pueden iniciar flujos con el componente [Lightning](https://developer.salesforce.com/docs/component-library/bundle/lightning-flow/documentation).

OmniStudio destaca en la exposición de contenido a sus sitios externos a través de la función OmniOut. Con OmniStudio y OmniOut, puede compilar sus formularios de OmniScript y componentes FlexCard en componentes estándar y ejecutarlos fuera de la plataforma en sitios o aplicaciones externos.

Ninguna de las tecnologías de formularios cubiertas en esta guía se admite oficialmente en plantillas de Mobile SDK hoy. Si el SDK móvil es esencial para su caso de uso, es mejor que cree su formulario de forma nativa en su aplicación móvil o cree una página Visualforce, teniendo en cuenta las directrices de [factores de forma](/docs/architect/es-mx/well-architected/guide/engaging#factor-de-forma) bien arquitectadas de Salesforce.

**Nota de hoja de ruta:** El equipo de Mobile SDK está trabajando activamente en la asistencia a LWC en páginas Visualforce.

### Controlador

Formularios dinámicos es perfecto si necesita utilizar los valores de su formulario para crear o actualizar un registro. Para cualquier función más allá de eso, deberá aprovechar Flow, OmniStudio o LWC. Esas funciones podrían incluir una capa de decisiones o iteraciones, o la generación de publicaciones o mensajes de email de Slack utilizando las entradas del formulario.

#### Preguntas para formular:

- ¿Qué acciones o lógica desea que se realicen en segundo plano?
- ¿Contiene su modelo de datos datos datos jerárquicos?
- ¿Necesitará su formulario completar sus operaciones en una sola transacción o entre múltiples transacciones?
- ¿Necesita integrar con sistemas externos?
- ¿Cuáles son sus requisitos de reutilización y modularidad?

<table>
  <colgroup>
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Registro y acciones</th>
      <th scope="col">Gestión de datos jerárquica</th>
      <th scope="col">Operar en una sola transacción</th>
      <th scope="col">Operar entre múltiples transacciones</th>
      <th scope="col">Integración</th>
      <th scope="col">Diseño modular y reutilización</th>
      <th scope="col">Empaquetado</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Formularios dinámicos</th>
      <td>No disponible</td>
      <td>No disponible</td>
      <td>No disponible</td>
      <td>No disponible</td>
      <td>No disponible</td>
      <td>No disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-roadmap">Roadmap</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td>No disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla + LWC</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
  </tbody>
</table>

Flow ofrece acciones estándar para publicar en Slack, enviar emails e interactuar con documentos Quip, de modo que no tiene que escribir código para estas operaciones. LWC ofrece interacciones enriquecidas con registros únicos y objetos relacionados a través del uso de adaptadores de red que interactúan con la [API de interfaz](https://developer.salesforce.com/docs/atlas.en-us.uiapi.meta/uiapi/ui_api_get_started.htm) de usuario. LWC también puede interactuar con múltiples registros al utilizar el cable para [getListInfoByName](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/reference_get_list_info_by_name.html).

[<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-controllernoheader.png" alt="Interacción LWC a través de adaptadores de red">Interacción de _componentes web Lightning a través de adaptadores de red_](/docs/architect/es-mx/reference-diagrams/guide/lightning-web-components-interaction-via-wire-adapters)

Como se mencionó anteriormente, OmniStudio utiliza Procedimientos de integración y Asignador de datos para capturar y transformar fácilmente datos externos e internos en Salesforce. Brilla en aplanar y ampliar conjuntos de datos con varios niveles de relaciones gracias a numerosas funciones libres de código que puede utilizar.

**Nota de hoja de ruta:** Flow pronto admitirá la capacidad de alterar recopilaciones de registros, así como gestionar datos jerárquicos.

Flow, OmniStudio y LWC se integran con Apex, de modo que puede cerrar fácilmente cualquier brecha en la solución que elija. Por ejemplo, si requiere filtrar registros desde un LWC, siempre puede utilizar el adaptador de red para Apex para crear consultas SOQL complejas. Si se deja influir por la historia basada en clics, considere Flow u OmniStudio como alternativas viables a un controlador Apex para sus necesidades del lado del servidor.

Una pregunta secundaria aquí es si desea confirmar acciones inmediatamente o aplazarlas a una parte concreta de su formulario. Esto es especialmente relevante si está en un formulario de varias páginas. Flujo facilita combinar entradas desde múltiples formularios (pantallas de flujo) y utilizarlas mucho más adelante en el asistente (flujo) para realizar algunas operaciones. De hecho, recomendamos diseñar flujos justo de esa forma (realizar acciones al final) en caso de que el usuario se desplace entre pantallas, cambiando sus respuestas.

#### Control de operaciones

Las transacciones y los [límites reguladores](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) son una forma de vida en Salesforce Platform. Si su caso de uso es bastante sencillo, es posible que no sea tan importante controlar en qué transacción se produce una operación concreta. Sin embargo, existen algunos casos de uso en los que es posible que desee combinar múltiples operaciones en una sola [transacción en](/docs/architect/es-mx/fundamentals/guide/architecture-basics#transacciones) vez de realizarlas en múltiples transacciones. Algunos ejemplos:

- **Para revertir o no revertir**: Esa es la cuestión. Supongamos que su formulario crea múltiples registros en segundo plano. Si no se crea el tercer registro, ¿se deben revertir los dos primeros registros? Si cada una de sus acciones son independientes entre sí, no dude en ejecutarlas en transacciones separadas. Sin embargo, si son dependientes y desea que el fallo de uno también revierta los otros, impleméntelos en una sola transacción. Si su formulario está en Flujo, puede utilizar el elemento Reversión en una ruta Fallo para revertir su transacción y garantizar la integridad de los datos.
- **Repercusión descendente en límites reguladores**: Especialmente cuando su formulario crea o actualiza un registro, considere cuáles son las implicaciones descendentes de esa operación. ¿Qué procesos, reglas de flujo de trabajo, desencadenadores de flujo, desencadenadores Apex u otros elementos en el orden de guardado se van a desencadenar basándose en este cambio de registro? ¿Y cómo afectan esos cambios colectivos a los límites reguladores que se consumen en esa transacción? Si un cambio de registro concreto dará como resultado muchos cambios descendentes que afectarán a sus límites, considere aislar ese cambio de registro en su propia transacción.
- **Procesamiento por lotes**: Incluso en un contexto de interfaz de usuario, es posible que necesite realizar múltiples actualizaciones por lotes juntas. Supongamos que su formulario de múltiples pantallas itera sobre un gran grupo de registros. En vez de confirmar una actualización de registro después de cada pantalla, espere a que haya recopilado las actualizaciones para todos los registros y luego envíe una solicitud para actualizar todos los registros.

Cuando utiliza Formularios dinámicos para crear o modificar un registro, solo siempre está realizando una operación, y esa operación es siempre el inicio de una transacción nueva neta.

Al crear un flujo de pantalla, tiene un control significativo sobre lo que sucede en una transacción concreta. Las pantallas y las acciones locales actúan como límites entre transacciones. Este es un resumen de alto nivel de cómo se gestionan las transacciones en la arquitectura de flujo de pantalla.

1. El usuario final interactúa con una pantalla y luego hace clic en **Siguiente**.
2. El cliente publica una solicitud en la API con las entradas.
3. La API recibe la solicitud y se abre una transacción y una conexión de base de datos. A continuación, la API llama al motor de flujos para invocar la solicitud.
4. El motor de flujos toma el relevo y sigue la ruta apropiada en la definición de flujo, hasta que alcanza un nodo Pantalla o Acción local. A continuación, el motor devuelve información sobre ese nodo a la API.
5. La API crea un objeto de respuesta que contiene los detalles de la siguiente pantalla para representar y devuelve ese objeto al cliente. En este punto, se confirman los cambios de la base de datos (por ejemplo, la [ejecución del pedido](/docs/architect/es-mx/fundamentals/guide/architecture-basics#manipulación-de-base-de-datos) de guardado) y se cierran la conexión y la transacción de la base de datos.
6. El cliente utiliza la respuesta de API para representar la siguiente pantalla con la que el usuario debe interactuar.
7. Repita el paso 1.

En otras palabras, las pantallas “rompen” transacciones. Cuando eso sucede, se confirma cualquier acción pendiente o DML, se cierra la transacción anterior y se inicia una nueva transacción.

<br/>

<img style="border:1px solid #e5e5e5;float:left;width:50%;margin:1rem 2rem 1rem 0rem" src="https://architect.salesforce.com/ns-assets/guide-forms-flow1.png" alt="flujo de pantallas múltiples">

El diseño correcto, qué operaciones agrupa en una transacción concreta, es su llamada. Veamos algunos ejemplos.

<br/>

<img style="border:1px solid #e5e5e5;float:right;width:50%;margin:1rem 2rem 1rem 0rem" src="https://architect.salesforce.com/ns-assets/guide-forms-flow2.png" alt="flujo de pantalla con transacciones separadas">

<br/>

A la izquierda, puede ver un flujo que recopila entradas entre múltiples pantallas y luego realiza varias acciones en una transacción.

<br/>

El flujo de la derecha realiza cada operación en una transacción separada.

<br/>
El equipo de Flujo presentó recientemente un nuevo elemento: El elemento Revertir registros le permite revertir una transacción completa si una sola operación falla en una serie de operaciones de la base de datos.

<br/>

<img style="border:1px solid #e5e5e5;float:right;width:50%;margin:1rem 2rem 1rem 0rem" src="https://architect.salesforce.com/ns-assets/guide-forms-flow3.png" alt="Flujo de pantalla con múltiples registros de creación">

<br/>
<br/>

Supongamos que tiene un flujo que crea registros, actualiza registros y luego crea más registros, como se ilustra en el siguiente flujo a la derecha.

<br/>

En este escenario, si los dos primeros elementos tienen éxito y el último falla, las dos primeras operaciones DML seguirán creando y actualizando esos registros mientras que el tercero no.

<br/>

<img style="border:1px solid #e5e5e5;float:left;width:50%;margin:1rem 2rem 1rem 0rem" src="https://architect.salesforce.com/ns-assets/guide-forms-flow4.png" alt="Flujo de pantalla con reversión">

<br/>

Utilizando el elemento Revertir registros, puede asegurarse de que se revierte toda la transacción si las tres operaciones tienen que producirse en tándem, como se ve en el flujo final a la izquierda.

Para obtener más detalles, consulte [Flujos en transacciones](https://help.salesforce.com/articleView?id=flow_concepts_transaction.htm) y [Flujo masivo en transacciones](https://help.salesforce.com/articleView?id=flow_concepts_bulkification.htm). La sección Automatizado de Salesforce Well-Architected también profundiza más sobre esto en [Manejo de datos](/docs/architect/es-mx/well-architected/guide/automated#gestión-de-datos).

Su capacidad de controlar la transacción desde un LWC se reduce a los servicios subyacentes que LWC está utilizando para realizar sus operaciones. Si está utilizando el componente base de formulario de registro Lightning, la operación subyacente (creación o actualización del registro) se produce en una transacción independiente en cuanto se envía el formulario.

En general, se aplican estas reglas:

- Cada llamada de API de la interfaz de usuario está aislada en su propia transacción.
- Si necesita realizar múltiples operaciones en una sola transacción, envíe las entradas a una tecnología del lado del servidor, como un controlador Apex o un flujo. Se aplican las reglas de transacciones regulares para esa tecnología.

#### Integraciones externas

Flow, OmniStudio y LWC admiten eventos de plataforma (para [arquitectura dirigida por](/docs/architect/es-mx/decision-guides/guide/event-driven) eventos) e integraciones de API. Además del código Apex personalizado, tanto Flow como OmniStudio admiten mecanismos declarativos para integrar una API.

Si necesita conectarse a una API de MuleSoft o bot de RPA, utilice Servicios de MuleSoft. Esto genera un Servicio externo.

[<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrations-mulesoftnoheader.png" alt="Integraciones externas a través de MuleSoft"> _Integraciones externas a través de API de MuleSoft y Bots RPA_](/docs/architect/es-mx/reference-diagrams/guide/external-integrations-via-mulesoft-apis-and-rpa-bots)

Si la API tiene un esquema de OpenAPI, cree un Servicio externo.

[<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrations-openapi-noheader.png" alt="Integraciones externas a través de OpenAPI"> _Integraciones externas en API con esquemas de OpenAPI_](/docs/architect/es-mx/reference-diagrams/guide/external-integrations-to-apis-with-openapi-schemas)

De lo contrario, utilice la función Llamada HTTP en Flujo o Acción HTTP en OmniStudio. La llamada HTTP de Flow tiene tecnología de Servicios externos.

[<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrations-callouts-noheader.png" alt="Integraciones externas mediante HTTP">_. Integraciones externas mediante HTTP_](/docs/architect/es-mx/reference-diagrams/guide/external-integrations-via-http)

OmniStudio cuenta con un conjunto enriquecido de funciones de integración que pueden llamar a sistemas externos con Procedimientos de integración y transformar los datos con Asignador de datos. (Consulte [Repercusión de objeto](#impacto-de-objeto) para obtener más información)

Independientemente de si lo implementa con Apex personalizado o un servicio externo, una llamada es una llamada. Esto es lo que necesita saber.

1. Una llamada puede tardar mucho tiempo.
2. Cuando una llamada se ejecuta de forma síncrona, se realiza mientras una transacción de base de datos está abierta.
3. Salesforce no le permite mantener una transacción de base de datos abierta si tiene operaciones de base de datos pendientes.

La principal limitación a tener en cuenta es el peligro de las llamadas **_transacciones sucias_**, donde realiza una operación de creación, actualización o eliminación y luego, en la misma transacción, ejecuta una llamada. Este patrón no está permitido debido a la consideración #3 anterior, que por supuesto existe debido a las consideraciones #1 y #2.

En Flujo, puede solucionar esta limitación rompiendo la transacción. Recuerde que las pantallas y las acciones locales reintroducen el contexto del navegador, lo que interrumpe la transacción. Aunque puede utilizar pantallas y acciones locales cuando trabaje con llamadas externas, recomendamos activar Control de transacciones en configuración avanzada invocable. Control de transacciones es una función de acciones invocables que le permite finalizar automáticamente la transacción antes de que se realice una llamada. Puede activar Control de transacciones seleccionando Iniciar siempre una nueva transacción en la sección Avanzado de una acción invocada.

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://architect.salesforce.com/ns-assets/guide-forms-flow5.png" alt="Integraciones externas a través de llamadas">  
La repercusión de las llamadas en la transacción es menos complicada con LWC. En términos generales, realizará sus operaciones de datos utilizando Lightning Data Service (LDS) y luego utilizará un controlador Apex para realizar la llamada externa. Este diseño le protege de transacciones sucias, ya que la llamada LDS está aislada en su propia transacción separada de la llamada Apex.

_Para obtener directrices más detalladas sobre llamadas Apex, servicios externos y funciones de integración de datos en general, consulte la [Guía del arquitecto para la integración de datos con Salesforce](/docs/architect/es-mx/decision-guides/guide/data-integration)._

#### Reutilización y modularidad

Formularios dinámicos no admite la reutilización. Cada Formulario dinámico está vinculado a una página de registro Lightning específica para un objeto específico (aunque puede asignar esa página de registro Lightning a múltiples aplicaciones, perfiles, etc.).

Del mismo modo que puede redactar bibliotecas, utilidades y componentes pensados para su uso en múltiples otros componentes, puede aplicar patrones de diseño similares al crear flujos con la potencia de **_subflujos_**. Guarde sus flujos en depósitos más pequeños y modulares, y luego llámelos desde otros flujos utilizando el elemento Flujo secundario. Si su diseño lo requiere, puede crear un flujo que sea independiente y útil como subflujo de otro.

OmniStudio está construido de forma inherente para la modularidad. Asignadores de datos, OmniScripts, FlexCards y Procedimientos de integración se crean de forma independiente y pueden funcionar indistintamente. Además, las FlexCards se pueden crear como componentes LWC que se pueden integrar en otros LWC, OmniScripts, páginas de registro y sitios de Experience Cloud.

Los flujos de pantalla, los OmniScripts y los LWC se pueden crear para su reutilización e integrar en una variedad de ubicaciones, incluyendo sitios externos y aplicaciones Lightning Out. Cuando diseña sus soluciones para que sean [componibles](/docs/architect/es-mx/well-architected/guide/composable), obtiene beneficios adicionales como adaptabilidad y estabilidad.

### Validación

Todas las tecnologías que se utilizan para crear o actualizar un registro se adhieren a la validación a nivel del sistema, ya sean reglas de validación clásicas o validación personalizada integrada en un desencadenador Apex. Independientemente de la tecnología que utilice para realizar un cambio de registro, cada cambio pasa por la orden de guardado. Eso significa que además de las reglas de validación, el cambio de registro se procesa por cualquier número de flujos antes o después de guardar, antes o después de desencadenadores, reglas de distribución, reglas de asignación y mucho más. Si aún no lo hizo, asegúrese de marcar y familiarizarse con el [orden de ejecución](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm) de Apex.

#### Preguntas para formular:

- ¿Tiene su formulario requisitos adicionales más allá de la validación a nivel del sistema?
- ¿Necesitará establecer campos obligatorios o de solo lectura de forma dinámica en el formulario?

<table>
  <colgroup>
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Respetar validación a nivel del sistema</th>
      <th scope="col">Validación a nivel de campo personalizada específica de este formulario</th>
      <th scope="col">Validación a nivel de campo personalizada</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Formularios dinámicos</th>
      <td class="guide-table-ok">Disponible</td>
      <td>No disponible</td>
      <td>No disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla</th>
      <td class="guide-table-ok">Disponible</td>
      <td>No disponible</td>
      <td class="guide-table-roadmap">Roadmap</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla + LWC</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
  </tbody>
</table>

Las entradas en una pantalla de flujo o paso de OmniScript no están vinculadas por naturaleza, de modo que el formulario en sí no se adhiere de forma nativa a la validación a nivel del sistema asociada con un objeto concreto. Sin embargo, los valores que utilice para crear o actualizar registros se procesan por la orden de guardado, lo que significa que pasan por la validación a nivel del sistema del objeto. Tenga en cuenta, sin embargo, que no todos los componentes de flujo de pantalla admiten la validación de entrada. A partir de Summer '24, los componentes de pantalla restantes que no admiten validación de entrada son Botones de opción, Lista de selección, Lista de selección múltiple, Grupo de casillas de verificación y Búsqueda de opción.

Al igual que los formatos de página, Formularios dinámicos le permite establecer la obligatoriedad y el estado de solo lectura en el nivel de página. Sin embargo, no puede sustituir la configuración a nivel del sistema.

Flujo proporciona flexibilidad para personalizar la validación en las entradas de un formulario. Aunque algunas comprobaciones se realizan en el cliente (como marcar campos obligatorios que faltan o valores incompatibles), ninguna de las validaciones del lado del cliente impide al usuario intentar navegar. La validación real se produce en el servidor. Cuando un usuario hace clic en **Siguiente**, Flujo envía las entradas al servidor para su validación. Si se devuelven entradas como no válidas, la navegación se bloquea y se muestra el error apropiado. El servidor valida las entradas comprobando:

1. La configuración de obligatoriedad de la entrada o si el valor ingresado es compatible con el tipo de datos subyacente.
2. Validación personalizada en esa entrada: Varios componentes estándar (casilla de verificación, divisa, fecha, fecha/hora, área de texto largo, número, contraseña y texto) admiten la validación personalizada por pantalla. Proporcione una expresión de fórmula booleana y un mensaje de error para mostrar cuando no se cumpla la expresión de fórmula.
3. Validación personalizada en el componente subyacente: Si está creando un LWC personalizado para un flujo, agregue su propio código de validación al método validate().

OmniStudio cuenta con gestión de validación y errores enriquecidos a través de la acción [Establecer error](https://help.salesforce.com/s/articleView?id=sf.os_set_errors_in_an_omniscript.htm&type=5) en combinación con [Vistas condicionales](https://help.salesforce.com/s/articleView?id=sf.os_conditionally_display_elements_using_the_conditional_view_property.htm&type=5) y el componente [Mensajería](https://help.salesforce.com/s/articleView?id=sf.os_display_messages_in_omniscripts_19551.htm&type=5).

En el lado de LWC, la mayoría de los componentes base realizan sus propias validaciones del lado del cliente. Por ejemplo, Lightning respeta la exigencia a nivel del sistema, pero no la exigencia a nivel de página. Para sus componentes personalizados, puede Build Your Own mecanismos de validación.

Los campos que requieren que los usuarios ingresen datos deben aparecer pronto en sus formularios. Siempre que sea posible, valide entradas de usuario en el lado del cliente antes de enviar formularios. Para obtener más mejores prácticas sobre la simplificación de sus formularios, consulte las directrices sobre [formularios](/docs/architect/es-mx/well-architected/guide/engaging#formularios) en Salesforce Well-Architected - Engaging.

### Seguridad

La seguridad es un tema complejo en general, y cuando se trata de crear formularios, hay una serie de consideraciones en las que podría ni siquiera haber pensado. A nivel fundacional, querrá asegurarse de que el formulario se está ejecutando en el contexto correcto y que los usuarios tienen los permisos que necesitan para trabajar con sus datos subyacentes. Pero más allá de eso, es posible que también desee tomar medidas adicionales para eliminar códigos o direcciones URL potencialmente maliciosos de campos de texto enriquecido, evitar que ciertos usuarios puedan acceder al formulario en absoluto o poner limitaciones en los tipos de lugares donde los administradores pueden integrar el formulario en el futuro. Asegúrese de documentar sus requisitos de seguridad minuciosamente antes de elegir una herramienta. La [Plantilla de política](/docs/architect/es-mx/resources/guide/security-policy-template) de seguridad bien arquitectada de Salesforce contiene directrices para este tipo de documentación.

#### Preguntas para formular:

- ¿Debe el formulario comprobar el acceso del usuario antes de realizar ciertas operaciones?
- ¿Debería limpiar las entradas de usuario?
- ¿Desea controlar quién puede acceder al formulario?
- ¿Desea controlar dónde se puede incrustar el formulario?

<table>
  <colgroup>
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Elevar permisos de usuario</th>
      <th scope="col">Controlar quién tiene acceso</th>
      <th scope="col">Restringir ubicaciones permitidas</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Formularios dinámicos</th>
      <td>No disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td>No disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td>No disponible</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td>No disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td>No disponible**</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla + LWC</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td>No disponible</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Disponible*</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <td colspan="4">*Requiere Apex<br>**Aunque los OmniScripts no pueden tener un conjunto especificado de ubicaciones de destino, las FlexCards sí.</td>
    </tr>
  </tbody>
</table>

#### Elevación de permisos de usuario

Cuando algo se ejecuta en **_contexto de usuario_**, Salesforce aplica una serie de comprobaciones de acceso, incluyendo la verificación de la seguridad a nivel de campo, permisos CRUD y acceso a registros basándose en las reglas de colaboración de su organización. Por ejemplo, los usuarios solo podrían ejecutar un formulario de actualización de casos si tienen la capacidad de actualizar casos, la seguridad a nivel de campo apropiada y el acceso al registro en cuestión. ¿Pero qué sucede si desea que los usuarios puedan realizar una operación concreta cuando están utilizando _su_ formulario, pero no a través de ningún otro formulario o interacción? Ahí es donde entra **_el contexto del_** sistema.

El contexto del sistema es una forma de elevar los permisos del usuario que ejecuta durante la sesión, de modo que el usuario no necesita, por ejemplo, Actualizar el acceso al objeto Caso para completar correctamente su formulario de actualización de casos. Esto es especialmente útil para comunidades no autenticadas. En vez de otorgar a los usuarios invitados habilidades potencialmente peligrosas, establezca su formulario para ejecutarse en contexto del sistema.

Por supuesto, el contexto del sistema es una espada de doble filo y debe utilizarla solo cuando sea necesario. Cuando un formulario se ejecuta en contexto del sistema, cada operación CRUD omite la colaboración y la seguridad a nivel de objeto y campo, no solo la operación específica que le importa. Tenga en cuenta también que el contexto del sistema no influye en quién considera Salesforce el actor: el nombre que ve en el campo Última modificación por. Para cada operación que realice su formulario, como la actualización de caso, el actor es el usuario que ejecuta incluso si el formulario se ejecuta en un contexto diferente.

Formularios dinámicos, OmniScripts y LWC siempre se ejecutan en contexto de usuario, y no hay forma de sustituir este comportamiento.

Los flujos de pantalla se ejecutan en contexto de usuario de forma predeterminada, pero puede establecerlos para ejecutarse en contexto del sistema. Es su elección si el flujo debe otorgar acceso a todos los datos o si aún debe aplicar acceso a nivel de registro como colaboración.

- Si incrusta un componente Lightning en un flujo que se ejecuta en contexto del sistema, el flujo no sustituye el contexto del componente. Si necesita omitir las comprobaciones de acceso de usuarios, recomendamos utilizar el flujo para realizar esas operaciones y pasar los datos apropiados dentro o fuera del componente Lightning. Algunos componentes listos para su uso (como Búsqueda) no pueden operar en contexto del sistema.
- Si su flujo llama a acciones Apex, hay algunos matices más que comprender. Si la clase Apex está establecida como colaboración heredada, se ejecuta en contexto del sistema con colaboración sin importar en qué esté establecido el flujo. Si la clase no tiene ninguna declaración de colaboración explícita, se ejecuta en contexto del sistema sin colaboración independientemente de la configuración del flujo. Si la clase está establecida como with sharing o without sharing, lo hace y sustituye el contexto del flujo.

**Consulta de registros en contexto del sistema con sitios de Experience Cloud:**

Si está ejecutando un flujo en contexto del sistema en un sitio de Experience Cloud, **especialmente no autenticado**, recomendamos almacenar solo campos específicos en sus elementos Obtener registros. Cuando está trabajando con Flow y pasa los resultados de un elemento Obtener registros a un subflujo, una acción invocable o un componente Lightning, todos los campos de ese objeto se pueden inspeccionar a través de las herramientas de desarrollador del navegador. Esto podría hacer que los campos estén disponibles para los usuarios de su sitio de Experience Cloud que no pretenda. Especificando campos específicos en sus elementos Obtener registros, puede garantizar que solo se exponen los campos correctos incluso con contexto del sistema activado.

Tenga en cuenta que la lógica de OmniScript se ejecuta en el lado del cliente, lo que permite a los atacantes modificar la ejecución esperada de un OmniScript _y_ ver respuestas a Procedimientos de integración, Asignadores de datos y llamadas de métodos Apex utilizando las herramientas de desarrollador del navegador. Cuando está utilizando OmniScript, recomendamos ejecutar lógica de negocio en el lado del servidor siempre que sea posible e implementar reglas de validación de entrada en cualquier método Apex expuesto a través de una [anotación @InvocableMethod](https://help.salesforce.com/s/articleView?id=sf.os_integration_procedure_invocation_55721.htm&type=5).

**Insumos de desinfección:**

Para proteger su organización de malos actores, considere también la desinfección de entradas. Supongamos que tiene una entrada en un formulario accesible públicamente que podría asignarse a un campo Texto enriquecido en su organización. Es posible que desee considerar la automatización que elimina cualquier HTML que podría ocultar direcciones URL maliciosas. En general, no es ideal implementar esta desinfección en el nivel del formulario, ya que podría tener cualquier número de orígenes escritos en estos campos. Recomendamos crear un flujo de actualización de campo rápida (antes de guardar) o utilizar un desencadenador Apex existente en el objeto para eliminar o modificar cualquier HTML potencial que se pueda ingresar en el formulario.

**_Mejores prácticas:_**

- _Deje que los flujos se ejecuten en su contexto predeterminado a menos que necesite elevar el acceso del usuario que ejecuta para una operación específica._
- _Evite ejecutar flujos en contexto del sistema para usuarios invitados por motivos de seguridad. Cree conjuntos de permisos con acceso de campo limitado asignado al perfil de usuario invitado del sitio de Experience Cloud en su lugar._
- _Cuando consulte registros en flujos ejecutados por contexto del sistema en sitios de Experience Cloud, solo almacene los campos que necesita en su elemento Obtener registros o Acciones invocables._
- _Si un flujo realiza una variedad de operaciones y no todas requieren acceso elevado, utilice subflujos para aislar las operaciones que deben ejecutarse en contexto del sistema._
- _Si tiene intención de incrustar un formulario en una página web externa, considere desinfectar las entradas de usuario para eliminar HTML utilizando un Flujo de actualización rápida de campos o Desencadenador Apex si eventualmente se asignarán a campos de Texto enriquecido para evitar posibles ataques de phishing de actores incorrectos._

#### Notas adicionales:

- OmniScripts, FlexCards y LWC se ejecutan en contexto de usuario de forma predeterminada.
- Los LWC se ejecutan en contexto de usuario de forma predeterminada y los flujos se ejecutan en contexto de usuario, pero puede sustituir eso en un controlador Apex.
- Las operaciones realizadas a través de la API de la interfaz de usuario se ejecutan en contexto de usuario.
- Las operaciones realizadas a través de un controlador Apex dependen de esa clase. Para realizar esas operaciones en modo sistema, establezca la clase Apex en with sharing o without sharing.

#### Control de acceso

Si necesita control sobre quién puede acceder a su formulario, a menudo puede buscar el contenedor en el que está incrustado el formulario. Por ejemplo, puede asignar páginas Lightning para que estén disponibles para aplicaciones, tipos de registro o perfiles concretos. Si ciertas entradas en su formulario son confidenciales, utilice reglas de visibilidad para controlar aún más qué se muestra a quién; esta función se aplica a Formularios dinámicos y flujos de pantalla.

Puede [restringir un flujo](https://help.salesforce.com/articleView?id=flow_distribute_security.htm) a perfiles o conjuntos de permisos concretos, de la misma forma que puede hacerlo con una clase Apex o una página Visualforce. De forma predeterminada, los flujos no están restringidos, lo que significa que cualquier usuario con el permiso de usuario Ejecutar flujos puede ejecutarlos.

Si está utilizando OmniStudio, puede configurar un [comprobador de permisos](https://help.salesforce.com/s/articleView?id=sf.os_add_an_apex_class_permissions_checker_1.htm&type=5) de clase Apex para garantizar que los usuarios requieren acceso explícito a la clase Apex que administra la acción remota llamada desde una API de OmniScript, Flexcard, Classic Card o REST.

- Tenga en cuenta que las comprobaciones de permisos de clase Apex están activadas de forma predeterminada para secuencias de comandos recién creadas. Sin embargo, tienen que activarse manualmente para cualquier secuencia de comandos existente
- Tenga en cuenta también que las comprobaciones de permisos de clases Apex solo se aplican a clases Apex. Recomendamos establecer permisos a nivel de perfil para [Procedimientos de integración y Asignadores de datos](https://help.salesforce.com/s/articleView?id=sf.os_security_for_dataraptors_and_integration_procedures_48147.htm&type=5) también.

Para obtener más detalles y mejores prácticas sobre permisos de usuario invitado, consulte:

- [Mejores prácticas de acceso a registros de usuario invitado](https://www.learnexperiencecloud.com/s/article/Guest-User-Record-Access-Development-Best-Practices#Pattern6)
- [Desarrollar sitios seguros: Usuarios autenticados e invitados](https://developer.salesforce.com/docs/atlas.en-us.communities_dev.meta/communities_dev/communities_dev_security_authenticated_and_guest_users.htm)

**_Mejores prácticas:_**

- _Si está exponiendo un flujo a usuarios invitados, otorgue al perfil de usuario invitado acceso solo a los flujos que necesitan. Aunque es posible agregar Ejecutar flujos al perfil de usuario invitado, consideramos que es una práctica arriesgada._
- _Tenga especial cuidado con los flujos que funcionan en contexto del sistema. Le recomendamos encarecidamente restringir esos flujos a un conjunto concreto de usuarios, ya que tienen menos controles y contrapesos para proteger sus datos._
- _Asegúrese de que cualquier OmniScript que ejecuta Apex en una comunidad de usuarios invitados tiene "with sharing" en la definición de clase Apex._
- _En su perfil Usuario invitado, asigne solo aquellas clases Apex a las que desea que los usuarios invitados puedan llamar o corre el riesgo de exponer involuntariamente lógica de negocio adicional a usuarios invitados._

Para LWC, puede comprobar las asignaciones de permisos del usuario que ejecuta para confirmar si tiene un permiso estándar o personalizado concreto. Directamente desde JavaScript, puede importar permisos de Salesforce desde los módulos con ámbito @salesforce/userPermission y @salesforce/customPermission. O bien puede utilizar Apex para comprobar lo mismo.

#### Control de integración

Los componentes web Lightning están disponibles en una ubicación determinada solo cuando se agregaron como un [destino](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.reference_configuration_tags) válido. Por ejemplo, puede hacer que un componente esté disponible en páginas de registro y no como un elemento de barra de utilidades.

Una vez activado un flujo de pantalla, está disponible en todas las ubicaciones donde se admiten los flujos de pantalla, independientemente de si pretendía que estuviera disponible en cualquier parte o no. Dicho esto, Flow Builder admite múltiples tipos de flujos que tienen pantallas. El tipo básico es Flujo de pantalla, pero existen otros tipos especializados restringidos a ubicaciones específicas. Por ejemplo, la aplicación móvil Field Service solo admite, lo adivinó, flujos móviles de Field Service. Lo mismo sucede con los flujos de solicitudes de contacto, que solo se admiten en Experience Cloud.

Independientemente del tipo de flujo, la persona que realiza el flujo no tiene control sobre dónde se puede incrustar el flujo. El flujo estará disponible en cada ubicación compatible con ese tipo de flujo.

Si está utilizando Salesforce Industries, hay una ligera advertencia cuando se trata de OmniScript: Aunque no puede especificar un destino para un OmniScript en sí, puede especificar uno para las FlexCards que desea integrar en él.

### Diseño de interacciones

Los formularios estáticos son cosa del pasado. Hoy en día, se trata de actualizar dinámicamente el formulario con las propiedades y los valores correctos para este usuario, esta vez, este lugar. Hablemos de lo que es posible en este sentido para las herramientas de creación de formularios de Salesforce.

#### Preguntas para formular:

- ¿Qué tipos de interacciones o condiciones deben desencadenar respuestas dinámicas en su formulario?
- ¿Necesitará ejecutar operaciones fuera de la pantalla en segundo plano cuando se rellene su formulario?
- ¿Necesitará establecer campos como visibles, obligatorios, de solo lectura o desactivados o cambiar el formato basándose en entradas de formulario?

<table>
  <colgroup>
    <col span="1" style="width: 12.5%;">
    <col span="1" style="width: 12.5%;">
    <col span="1" style="width: 12.5%;">
    <col span="1" style="width: 12.5%;">
    <col span="1" style="width: 12.5%;">
    <col span="1" style="width: 12.5%;">
    <col span="1" style="width: 12.5%;">
    <col span="1" style="width: 12.5%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Ejecutar operaciones de datos fuera de pantalla</th>
      <th scope="col">Valores condicionales y cálculos</th>
      <th scope="col">Visibilidad condicional</th>
      <th scope="col">Requisito condicional</th>
      <th scope="col">Formato condicional</th>
      <th scope="col">Estado de solo lectura condicional</th>
      <th scope="col">Estado desactivado condicional</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Formularios dinámicos</th>
      <td>No disponible</td>
      <td>No disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td>No disponible</td>
      <td class="guide-table-roadmap">Roadmap</td>
      <td>No disponible</td>
      <td>No disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible**</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible*</td>
      <td>No disponible</td>
      <td class="guide-table-ok">Disponible**</td>
      <td class="guide-table-ok">Disponible**</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla + LWC</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <td colspan="8">*Limitado a componentes que utilizan un selector de recursos y no una casilla de verificación estática<br>**Beta limitada</td>
    </tr>
  </tbody>
</table>

La interactividad de flujos de pantalla es ahora una realidad gracias a Pantallas reactivas. La reactividad permite que los componentes individuales en una pantalla de flujo se comuniquen entre sí, haciendo que los flujos de pantalla sean infinitamente más potentes.

**Ejecutar operaciones de datos fuera de pantalla:** Los flujos de pantalla ofrecen un enfoque declarativo para obtener datos en la misma pantalla a través de Acciones de pantalla. Las acciones de pantalla pueden permitirle desencadenar flujos iniciados automáticamente en cualquier cambio en la pantalla o cuando un usuario hace clic en un componente Botón de acción. Luego puede asignar los resultados de estos flujos iniciados automáticamente a la misma pantalla, eliminando la necesidad de que los usuarios naveguen a otra pantalla.

LWC ofrece una gama completa de adaptadores de red que le permiten acceder a datos de Salesforce para rellenar datos en los componentes de su formulario de forma dinámica, y permite a los desarrolladores actualizar, eliminar y crear registros a través de controladores Apex.

[<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-offscreendataoperations-noheader.png" alt="Operaciones de datos fuera de pantalla de componentes web Lightning">Operaciones de _datos fuera de pantalla_](/docs/architect/es-mx/reference-diagrams/guide/lightning-web-components-off-screen-data-operations)

**Visibilidad:** La visibilidad se puede controlar de forma dinámica en todas las herramientas de creación de formularios. Formularios dinámicos, Flow Builder y OmniStudio solucionan esto con funciones de visibilidad de componentes. Con esto, puede mostrar u ocultar campos de forma declarativa basándose en otros valores en el formulario o si el usuario está en un dispositivo móvil o no.

- Con Formularios dinámicos, la visibilidad se puede controlar basándose en valores de campo de registro, registros relacionados a través de campos de búsqueda y factor de forma.
- Con Flujo, puede basar una regla de visibilidad en otras entradas en la pantalla, así como otros recursos rellenados anteriormente en el flujo como fórmulas o valores de otros registros.
  - **Reglas basadas en dispositivos:** No es obvio desde el principio, pero puede utilizar una fórmula para mostrar u ocultar un campo concreto cuando el usuario está en un dispositivo móvil. Escriba una fórmula de flujo que compruebe el valor de la variable global \$User.UIThemeDisplayed. Si el valor es Theme4t, el usuario está en la aplicación móvil Salesforce.
  - **Evaluación de otros recursos:** Las referencias manuales de variables y fórmulas solo se evalúan en el servidor. Por lo tanto, cualquier valor que tenga ese recurso cuando se represente la pantalla por primera vez es el valor que tendrá hasta que navegue a otra pantalla. En la navegación, el tiempo de ejecución del flujo envía una solicitud al motor de flujos (el servidor) y obtiene los valores más recientes de las variables y fórmulas manuales. Si espera que su regla de visibilidad se actualice a medida que el usuario pasa por una única pantalla (por ejemplo, desenfoque), asegúrese de hacer referencia únicamente a valores de los otros componentes de la pantalla.
- Con OmniStudio, puede mostrar u ocultar componentes condicionalmente configurando una Propiedad de vista condicional. Sin embargo, no puede agregar más de una propiedad de vista condicional para una entrada.

**Estados de entrada condicionales:** Si necesita controlar dinámicamente cualquier otra propiedad, como si un campo es obligatorio, está desactivado o es de solo lectura, tiene algunas opciones. Como se espera, LWC le proporciona un control reactivo completo sobre su estado de entrada. Con componentes Flujo de pantalla reactivos, puede controlar dinámicamente atributos de componentes como Solo lectura, Desactivado y Obligatorio para componentes estándar que lo admiten, mientras que OmniStudio admite el espectro completo de atributos específicos de componentes. Si sus requisitos dictan que necesita Flujo y el componente no admite un estado de atributo específico, puede crear un LWC incrustable para alcanzar un estado de entrada dinámico.

Si necesita controlar dinámicamente cualquier otra propiedad, como si un campo es obligatorio o de solo lectura, su mejor apuesta a corto plazo es LWC, donde tiene el control completo. Eso es especialmente cierto si tiene requisitos personalizados sobre cómo gestionar el desenfoque o el onclick.

LWC reactivos en flujos de pantalla: Al crear LWC que pueden reaccionar y cambiar otros componentes en un flujo de pantalla, consulte esta guía [Mejores prácticas LWC para flujos](https://developer.salesforce.com/blogs/2023/02/lwc-best-practices-for-screen-flows) de pantalla para garantizar que sus componentes se integran bien en el motor de tiempo de ejecución de flujos y funcionan como se espera en el futuro.

<table>
  <colgroup>
    <col span="1" style="width: 33%;">
    <col span="1" style="width: 33%;">
    <col span="1" style="width: 33%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Gestión de eventos estándar (desenfoque, enfoque)</th>
      <th scope="col">Gestión de eventos personalizados</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Formularios dinámicos</th>
      <td>No disponible</td>
      <td>No disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla</th>
      <td>No disponible</td>
      <td>No disponible</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td>No disponible</td>
      <td class="guide-table-ok">Disponible*</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla + LWC</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <td colspan="3">*El Tiempo de ejecución estándar de OmniStudio no admite Pub/Sub, pero admite Windows postMessage</td>
    </tr>
  </tbody>
</table>

Ahora para eventos personalizados. Si algunas de sus entradas o el formulario completo necesitan comunicarse con otra cosa en la página, LWC es su única opción.

- Para comunicarse dentro del mismo árbol DOM, utilice la [**interfaz CustomEvent**](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events).
- Para comunicarse en el DOM, utilice [**Servicio Lightning Messaging**](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel).
- Si Lightning Messaging Service [no es compatible](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel_considerations) con su contenedor de destino, utilice el **módulo pub/sub**.

#### Recursos adicionales

- Para obtener más detalles, consulte [Comunicarse con eventos](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/events) y [comunicarse a través del DOM](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events_pubsub) en la _Guía del desarrollador_ de componentes web Lightning.
- Para OmniStudio, consulte [Comunicarse con OmniScript desde un componente web Lightning.](https://help.salesforce.com/s/articleView?id=sf.os_communicate_with_omniscript_from_a_lightning_web_component_18222.htm&type=5)

### Estilo

Para proporcionar la mejor experiencia de usuario, deberá asegurarse de que el estilo de su formulario es coherente con el resto de la aplicación o el sitio donde está integrado. Lograr esto puede significar cualquier cosa, desde la utilización de plantillas estándar proporcionadas por Salesforce hasta la creación de CSS personalizado que utiliza completamente cada píxel en el diseño para proporcionar un aspecto más nítido.

#### Preguntas para formular:

- ¿Qué tan sofisticado es su estilo y CSS deseados?
- ¿Necesita un estilo personalizado y perfecto para los píxeles o está de acuerdo con los temas estándar?

<table>
  <colgroup>
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
    <col span="1" style="width: 25%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Estilo directo</th>
      <th scope="col">Temas de organización y Experience Builder</th>
      <th scope="col">Estilo perfecto para píxeles</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Formularios dinámicos</th>
      <td>No disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td>No disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla</th>
      <td>No disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-roadmap">Roadmap</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td class="guide-table-ok">Disponible*</td>
      <td>No disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla + LWC</th>
      <td>No disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td>No disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <td colspan="4">*Solo tarjetas Flex</td>
    </tr>
  </tbody>
</table>

FlexCards es el único producto cubierto en esta guía que le permite controlar declarativamente el estilo y el formato de la interfaz de usuario que está creando en la herramienta directamente: ya sean los márgenes y el relleno, la tipografía, los colores, etc.

Tanto Formularios dinámicos como flujos respetan funciones de tema declarativo. Si necesita control más allá de lo que admiten [los temas Salesforce](https://help.salesforce.com/articleView?id=brand_your_org_in_lightning_experience.htm&mode=1), los [conjuntos de marca](https://help.salesforce.com/articleView?id=community_designer_brandsets.htm) Experience Builder o los [sitios LWR Experience Cloud](https://developer.salesforce.com/docs/atlas.en-us.exp_cloud_lwr.meta/exp_cloud_lwr/brand_overview.htm), considere una solución programática.

Para equipos que se sienten cómodos trabajando con CSS, tiene un par de opciones:

- Los flujos y los LWC heredan [tokens de diseño estándar](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/tokens_standard.htm).
- OmniScripts y FlexCards incluyen compatibilidad para un sistema de diseño personalizable: [Newport](https://help.salesforce.com/s/articleView?id=sf.os_customize_omniscripts_and_flexcards_with_the_newport_design_system.htm&type=5).
- Con LWC, puede redactar sus propios componentes y controlar completamente el HTML y CSS para ellos.

Siempre que sea posible, recomendamos utilizar temas y sistemas de diseño, de modo que su aspecto se aplique de forma coherente en todo su contenido.

Recordatorio: Puede integrar componentes Lightning en flujos. Por lo tanto, si necesita un control perfecto de los píxeles sobre el aspecto de su formulario pero desea utilizar los otros beneficios de los flujos, como el modelo de navegación, puede tener lo mejor de ambos mundos. El mismo principio se aplica a OmniScripts y FlexCards.

### Formato

La selección de un buen formato es crucial para diseñar formularios simplificados que permiten el ingreso de datos rápido y eficiente y aumentan la integridad de los datos. Consulte [Formularios de Salesforce](/docs/architect/es-mx/well-architected/guide/engaging#formularios) bien arquitectados para obtener más información sobre este tema.

#### Preguntas para formular:

- ¿Cómo puede utilizar el formato de su formulario para optimizar experiencias de usuario?
- ¿Cómo puede presentar datos existentes a sus usuarios de una forma que les facilite ingresar nuevos datos en sus formularios?

<table>
  <colgroup>
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
    <col span="1" style="width: 14.28%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">2 columnas</th>
      <th scope="col">4 columnas</th>
      <th scope="col">Más allá de 4 columnas</th>
      <th scope="col">Bloques de datos repetitivos</th>
      <th scope="col">Ficha Contenedores</th>
      <th scope="col">Contenedores de acordeón</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Formularios dinámicos</th>
      <td class="guide-table-ok">Disponible</td>
      <td>No disponible</td>
      <td>No disponible</td>
      <td>No disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td>No disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td>No disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible*</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla + LWC</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <td colspan="7">*Las fichas se pueden utilizar si se incrustan datos en una FlexCard en un OmniScript</td>
    </tr>
  </tbody>
</table>

Formularios dinámicos admite formatos de dos columnas y puede dividirse en secciones individuales con campos. Estas secciones se pueden colocar en componentes como fichas y acordeones para crear formatos fáciles de utilizar y organizados.

Los flujos se pueden representar opcionalmente utilizando el componente Sección. Con secciones, puede agregar hasta cuatro columnas y tantas secciones como desee en la pantalla de flujo. El componente también tiene capacidad de respuesta a la anchura de la pantalla, de modo que puede funcionar en pantallas más pequeñas. Por último, le proporciona la capacidad de aplicar visibilidad condicional a toda la sección, facilitando la aplicación masiva de visibilidad a múltiples campos dentro de la sección. Las secciones de flujo también admiten encabezados de columna y proporcionan una experiencia similar a un acordeón donde los usuarios pueden contraer la sección completa haciendo clic en la etiqueta.

Los OmniScripts incluyen una variedad de opciones de formato para mostrar campos y datos. Puede crear secciones de datos con hasta 12 columnas incluyendo acordeones contraíbles condicionalmente.

Con LWC, puede utilizar Lightning y el campo Lightning para controlar el formato. Las únicas restricciones de formato son las de HTML/CSS. Lightning respeta la configuración de la sección en el formato de página asociado; por ejemplo, si una sección tiene dos columnas en el formato de página, tiene dos columnas en este componente.

### Traducción

Si su formulario será accesible para usuarios en diferentes regiones o que hablan diferentes idiomas, deberá asegurarse de que la herramienta que utilizará para crearlo cumpla sus requisitos de localización. Consulte [Salesforce Well-Architected - Localización](/docs/architect/es-mx/well-architected/guide/compliant#localización) para obtener directrices y recomendaciones adicionales. En el caso de formularios específicamente, los requisitos de localización implican normalmente traducir elementos de texto a otros idiomas.

#### Preguntas para formular:

- ¿Se utilizará su formulario en más de un país o región?
- ¿Necesita el texto de su formulario estar traducido a otros idiomas?

<table>
  <colgroup>
    <col span="1" style="width: 33%;">
    <col span="1" style="width: 33%;">
    <col span="1" style="width: 33%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Etiquetas ingresadas en el generador</th>
      <th scope="col">Etiquetas en el código</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Formularios dinámicos</th>
      <td class="guide-table-ok">Disponible*</td>
      <td>No disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla + LWC</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td>No disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <td colspan="3">*Solo encabezados de sección de campo</td>
    </tr>
  </tbody>
</table>

Si localizó sus campos personalizados, esas etiquetas traducidas se respetan en Formularios dinámicos. Formularios dinámicos también respeta las [etiquetas personalizadas que asignó a etiquetas y atributos](https://help.salesforce.com/s/articleView?id=platform.lightning_page_components_use_expressions_for_labels.htm&type=5) de componentes en Lightning App Builder.

Con el poder de Sistema de traducción, Flow admite la traducción de etiquetas de cara al usuario para todos los componentes de pantalla estándar y personalizados. Puede localizar la etiqueta, el texto de ayuda y el mensaje de error de estos componentes de pantalla: Texto, Área de texto largo, Número, Divisa, Casilla de verificación, Botones de opción, Lista de selección, Lista de selección múltiple, Grupo de casillas de verificación, Contraseña, Fecha y Fecha/hora.

No hay compatibilidad de traducción integrada para acciones listas para su uso, como Enviar email o Publicar en Chatter. Sin embargo, ¡hay una solución! Si define las etiquetas traducidas con una [etiqueta personalizada](https://help.salesforce.com/articleView?id=cl_about.htm), puede hacer referencia a esa etiqueta personalizada en la acción o el componente cuando la configura en Flow Builder. Cree una fórmula de flujo que haga referencia a la etiqueta personalizada y haga referencia a esa fórmula en los lugares apropiados de su flujo.

Los OmniScripts utilizan etiquetas personalizadas para traducciones. Consulte [este documento](https://help.salesforce.com/s/articleView?id=sf.os_create_multi_language_omniscripts.htm) de ayuda para que sus OmniScripts estén listos para varios idiomas.

Ahora para LWC. Algunos componentes base heredan automáticamente traducciones de los campos, el texto de ayuda y los mensajes de validación del objeto asociado si se configuraron en Sistema de traducción (por ejemplo: Lightning).

Si necesita introducir etiquetas traducibles novedosas en su código, las etiquetas personalizadas siguen siendo el héroe desconocido. Declare la etiqueta personalizada que necesita y luego impórtela en su componente desde el módulo con ámbito @salesforce/label.

### Automatización de pruebas de la interfaz de usuario

Existen varias herramientas de automatización de pruebas de extremo a extremo disponibles (por ejemplo, Selenium), que le permitirán simular cómo interactúa el usuario con su formulario. Puede redactar estas pruebas para cualquier interfaz de usuario estándar o personalizada, incluyendo páginas Lightning y flujos de pantalla. Sin embargo, es importante tener en cuenta que estos tipos de pruebas no pueden verificar los resultados de cada método que se está realizando. Asegúrese de tener esto en cuenta cuando piense en sus requisitos para la automatización de pruebas de la interfaz de usuario.

#### Preguntas para formular:

- ¿Necesita pruebas automatizadas para su formulario?
- ¿Qué tipos de pruebas necesita realizar?
- ¿Qué nivel de granularidad necesita en sus automatizaciones de prueba?

<table>
  <colgroup>
    <col span="1" style="width: 33%;">
    <col span="1" style="width: 33%;">
    <col span="1" style="width: 33%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Pruebas de unidad</th>
      <th scope="col">Automatización de extremo a extremo</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Formularios dinámicos</th>
      <td>No disponible</td>
      <td class="guide-table-ok">Disponible*</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla</th>
      <td>No disponible</td>
      <td class="guide-table-ok">Disponible*</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td class="guide-table-ok">Disponible*</td>
      <td class="guide-table-ok">Disponible*</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla + LWC</th>
      <td class="guide-table-ok">Disponible*</td>
      <td class="guide-table-ok">Disponible*</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <td colspan="3">*Requiere código</td>
    </tr>
  </tbody>
</table>

Tenga en cuenta sus requisitos para la automatización de pruebas de la interfaz de usuario.

Las **pruebas de unidades** permiten una automatización y validación más granulares que funcionan con herramientas y sistemas de CI/CD estándar de la industria, que pueden probar la lógica de negocio de componentes, su controlador JavaScript y sus resultados. Pasando exclusivamente con código bajo no podrá realizar pruebas de autoría, pero Salesforce prueba rigurosamente nuestras ofertas de extremo a extremo.

Si los métodos de su componente son lo suficientemente complejos como para que desee que se prueben individualmente, coloque los métodos en archivos JavaScript exclusivos. De ese modo puede importarlos en un LWC y en una prueba de Jest con algo parecido a `import { sort } from 'c/utils';`.

Consulte Automatización de pruebas de la [interfaz de usuario](https://developer.salesforce.com/blogs/2020/01/ui-test-automation-on-salesforce.html) para obtener una comparación de las diversas opciones que tiene para crear una automatización integral en Salesforce. Se incluyen consideraciones sobre cuándo utilizar una solución sin código desde un ISV, Build Your Own solución de automatización de pruebas personalizada o utilizar un marco de trabajo de prueba de código abierto como Selenium WebDriver o WebdriverIO. Estas soluciones son válidas para cualquier interacción de la interfaz de usuario en Salesforce, ya sea un Formulario dinámico en una página Lightning, un flujo de pantalla en una barra de utilidades o un LWC en un flujo en una acción rápida.

### Mediciones

Después de implementar su formulario en un entorno de producción, querrá asegurarse de que se está utilizando de forma efectiva. Dependiendo de su caso de uso, esto puede significar cualquier cosa, desde simplemente realizar un seguimiento del número de veces que se completó hasta la cantidad de tiempo que los usuarios emplean rellenándolo antes de enviar su información. Asegúrese de identificar los KPI que desea realizar un seguimiento antes de seleccionar una herramienta.

#### Preguntas para formular:

- ¿Necesita realizar un seguimiento del uso de su formulario?
- ¿Qué indicadores clave de desempeño determinarán si su formulario se está utilizando de forma efectiva?

<table>
  <colgroup>
    <col span="1" style="width: 20%;">
    <col span="1" style="width: 20%;">
    <col span="1" style="width: 20%;">
    <col span="1" style="width: 20%;">
    <col span="1" style="width: 20%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Vistas de página</th>
      <th scope="col">Tiempo empleado en el formulario</th>
      <th scope="col">Realizar seguimiento de la cumplimentación de formularios</th>
      <th scope="col">Realizar un seguimiento del índice de éxito</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Formularios dinámicos</th>
      <td class="guide-table-ok">Disponible**</td>
      <td>No disponible</td>
      <td>No disponible</td>
      <td>No disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible*</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible*</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla + LWC</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible*</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Disponible**</td>
      <td class="guide-table-ok">Disponible*</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <td colspan="5">*Disponible cuando Tiempo de ejecución de OmniStudio basado en paquetes está activado<br>** Disponible realizando un seguimiento del uso de la página Lightning principal</td>
    </tr>
  </tbody>
</table>

Si necesita realizar un seguimiento del uso general y la adopción de su formulario, comience con las herramientas de código bajo. Tanto Formularios dinámicos como Flujos de pantalla son rastreables utilizando tipos de reportes personalizados listos para su uso, aunque obtendrá más granularidad de los reportes de seguimiento de Flujo de pantalla. Si necesita realizar un seguimiento del uso de un LWC, la disponibilidad de uso inmediato depende de dónde esté utilizando ese LWC. Si está en una página Lightning, lo que esté disponible para el seguimiento del uso de la página Lightning se aplica a su LWC. La misma historia se aplica a los LWC incrustados en flujos.

Los Formularios dinámicos en sí no son detectables de forma inmediata, aunque puede realizar un seguimiento del uso de la página Lightning principal a través de [objetos de uso Lightning](https://help.salesforce.com/articleView?id=lex_usage_reports.htm). Para realizar un seguimiento de las páginas Lightning estándar, utilice el tipo de reporte personalizado _Usuarios con Lightning Usage by Page Metrics_. Para lo mismo en páginas Lightning personalizadas, utilice el tipo de reporte personalizado _Usuarios con Lightning Usage by FlexiPage Metrics_.

Para realizar un seguimiento de la adopción de su formulario específico (no solo la página en la que reside), Flow le tiene cubierto. Utilice el “Reporte de flujo de muestra: Flujos de pantalla” para responder a preguntas como:

- ¿Cuál es el índice de realización de este formulario? ¿Está siendo bien adoptado?
- ¿Cuánto tardan los usuarios en rellenar este formulario?
- ¿En qué pantalla emplean los usuarios más tiempo?
- ¿Con qué frecuencia navegan los usuarios hacia atrás?
- ¿Con qué frecuencia se producen errores?

Si el reporte estándar no cumple sus necesidades, duplíquelo para realizar sus propios cambios o Build Your Own desde cero utilizando el tipo de reporte _Flujos de pantalla_.

Si está utilizando el tiempo de ejecución de OmniScript basado en paquetes, puede utilizar [OmniStudio para Vlocity Tracking Service](https://help.salesforce.com/s/articleView?id=sf.os_vlocity_tracking_service.htm&type=5). Este servicio realiza un seguimiento de cualquier tipo de evento. Por ejemplo, puede realizar un seguimiento del tiempo que se tarda en completar los pasos en un OmniScript para identificar mejoras de procesos. Está en la hoja de ruta del equipo de OmniStudio admitir este servicio en OmniStudio estándar.

Para realizar un seguimiento de lo mismo para un LWC que no está integrado en un flujo de pantalla, OmniScript o página Lightning, no hay ninguna opción lista para su uso. Puede crear una solución personalizada utilizando Apex.

### Empaquetado e implementación

Cuando necesite implementar su solución en entornos superiores para pruebas o implementación en producción, es posible que esté acostumbrado a utilizar conjuntos de cambios o DevOps Center para hacerlo. Formularios dinámicos, Flujos y LWC son completamente compatibles con esas opciones de implementación. OmniStudio requiere una herramienta separada: [IDX Workbench](https://help.salesforce.com/s/articleView?language=en_US&id=sf.os_idx_workbench_desktop_application.htm&type=5).

#### Preguntas para formular:

- ¿Cómo piensa implementar su formulario?
- ¿Se distribuirá su formulario a más de una organización de Salesforce?

<table>
  <colgroup>
    <col span="1" style="width: 16.66%;">
    <col span="1" style="width: 16.66%;">
    <col span="1" style="width: 16.66%;">
    <col span="1" style="width: 16.66%;">
    <col span="1" style="width: 16.66%;">
    <col span="1" style="width: 16.66%;">
  </colgroup>
  <thead>
    <tr>
      <th scope="col"></th>
      <th scope="col">Paquetes gestionados de primera generación (1GP)</th>
      <th scope="col">Paquetes gestionados de segunda generación (2GP)</th>
      <th scope="col">Paquetes desbloqueados</th>
      <th scope="col">Conjuntos de cambios</th>
      <th scope="col">DevOps Center</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Formularios dinámicos</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">OmniStudio</th>
      <td>No disponible</td>
      <td>No disponible</td>
      <td>No disponible</td>
      <td>No disponible*</td>
      <td>No disponible*</td>
    </tr>
    <tr>
      <th scope="row">Flujo de pantalla + LWC</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <th scope="row">LWC</th>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
      <td class="guide-table-ok">Disponible</td>
    </tr>
    <tr>
      <td colspan="6">*Utilice IDX Workbench para implementar Soluciones de OmniStudio en otras organizaciones.</td>
    </tr>
  </tbody>
</table>

Si es un ISV o socio que planea empaquetar su solución para su distribución en AppExchange, recomendamos consultar primero Formularios dinámicos, Flujos y LWC. OmniStudio no admite el empaquetado.

## Temas adicionales

### Navegación del continuo de código bajo a código pro

Esta guía se ha centrado en ayudarle a comprender qué funciones y nivel de personalización es posible con Formularios dinámicos, flujos de pantalla, OmniStudio y LWC. A un nivel superior:

<img align="left" style="border:1px solid #e5e5e5;float:left;width:50%;margin-right:2rem" src="https://architect.salesforce.com/ns-assets/guide-forms-lowcode-continuum.png" alt="Continuo de código bajo a código pro">

<br>

- LWC es la opción más personalizable y robusta para crear un formulario, pero tiene el menor número de salvaguardas. Depende de usted crear un componente de una forma que garantice la [seguridad](/docs/architect/es-mx/well-architected/guide/secure) y [la escalabilidad](/docs/architect/es-mx/well-architected/guide/reliable#escalabilidad).
- Formularios dinámicos es el menos flexible, pero hay muchas menos oportunidades de pasos en falso.
- Flow y OmniStudio se encuentran en algún punto intermedio, más potente que Formularios dinámicos pero no al nivel de LWC. Del mismo modo, tienen menos barandillas que Formularios dinámicos pero son más difíciles de romper que el código personalizado.

Si múltiples herramientas se ajustan a la factura, la decisión se reduce a qué herramienta es la correcta para su equipo. Otras [guías de decisiones](/decision-guides) de arquitectos presentan aspectos adicionales a tener en cuenta al tomar esa decisión.

No entraremos en los detalles de cada uno de esos aspectos aquí, pero lo que haremos será interpretarlos para las herramientas específicas que este documento está evaluando.

**Habilidades especializadas**: ¿Cuánta experiencia tiene su equipo en las herramientas que está comparando? ¿Cuántos fabricantes están bien familiarizados con LWC o JavaScript? ¿Qué hay de los creadores que son expertos en Flow Builder o que han expresado interés en hundirse? En términos generales, las habilidades de flujo y Formularios dinámicos son más alcanzables para una población más amplia de personas que crean formularios. Formularios dinámicos es la herramienta de creación de formularios más declarativa y siempre será más fácil de aprender que Flujo. Dicho esto, el equipo de Flow se compromete a reducir ese listón lo más posible. En términos de complejidad, OmniStudio se encuentra en algún punto entre Flow y LWC y ofrece superpoderes de creación de formularios significativos.

**Delegación de entrega**: Solo porque algunos de sus requisitos requieren LWC no significa que toda su solución tenga que crearse con LWC. Considere cómo puede crear su solución de forma modular, de modo que las piezas que requieren LWC estén codificadas y las piezas que no lo requieren estén construidas en una solución de código bajo. Al hacerlo se maximiza la eficiencia de un equipo diverso y se garantiza que cada individuo esté resolviendo problemas apropiados para su especialización.

Ahora hablemos de Flujo y LWC. Con Componentes de pantalla reactivos, los componentes de flujo de pantalla ahora pueden hablar entre sí en la misma pantalla desbloqueando un cofre de herramientas completamente nuevo para arquitectos, administradores y desarrolladores. Los desarrolladores ahora pueden crear componentes modulares específicos que se pueden reutilizar en toda la organización, potenciando la productividad para todos los miembros del equipo. Los desarrolladores pueden centrarse en resolver nuevos retos y ahorrar tiempo utilizando una mezcla de componentes Flujo estándar y personalizados para lograr el dinamismo de las formas. Con componentes reactivos en Flujo, nunca ha habido un momento más apropiado para mezclar Flujo y LWC al crear sus formularios.

**Mantenibilidad y propiedad a largo plazo**: Si tiene un formulario de múltiples pasos, es una buena idea comenzar con Flujo o una mezcla de Flujo y LWC. Si tiene un equipo de código bajo manteniendo la solución, piense en cómo puede hacer que la solución sea lo más configurable y ampliable posible para esa audiencia. Sea cual sea la herramienta que elija, organice su solución en unidades [componibles](/docs/architect/es-mx/well-architected/guide/composable) para mejorar la capacidad de mantenimiento y la estabilidad.

### Formatos de página

En adelante, la forma recomendada de configurar páginas de detalles de registro es Formularios dinámicos en el Generador de aplicaciones Lightning utilizando páginas Lightning. Ha pasado mucho tiempo desde que tenemos formatos de página mejorados, y esa tendencia continuará. Este es el motivo:

- Formularios dinámicos son más flexibles: puede colocar campos y secciones donde desee directamente en Lightning App Builder, donde puede aprovechar las secciones, fichas y acordeones. Del mismo modo que puede hacer con componentes en la página Lightning, puede controlar la visibilidad de sus campos y secciones sin definir múltiples formatos de página o tipos de registro.
- Con los componentes Acordeón y Ficha, puede restringir la cantidad de campos que se muestran inicialmente. ¿Adivina lo que eso significa? Tiempos de carga de página más rápidos.
- La gestión de formatos es más sencilla con páginas Lightning, ya que puede gestionar todo acerca de sus páginas desde el Generador de aplicaciones Lightning, ya sean los contenidos de la página o los usuarios que tienen acceso a la página. Ya no es necesario realizar actualizaciones en su formato de página para realizar un cambio en su página Lightning. Sin mencionar que con el poder de las reglas de visibilidad, ya no tiene que crear varias páginas (o formatos de página) para controlar quién ve qué campos cuándo. Eso también significa que solo necesita asignar a los usuarios una página Lightning en vez de asignar una página Lightning y un formato de página.

Recomendamos utilizar Formularios dinámicos siempre que sea posible y volver a los formatos de página solo cuando sea necesario. Como siempre, damos la bienvenida a comentarios en el [Intercambio de ideas](https://ideas.salesforce.com/s/) sobre las mejoras que podrían tener mayor repercusión en su organización.

### Desempeño

Cualquier consideración de desempeño relacionada con Formularios dinámicos, flujos de pantalla, OmniStudio y LWC se centra en qué marco de trabajo se encuentran esas tecnologías. Aquellos que están basados en LWC (además, por supuesto, de un LWC) van a superar a aquellos que están basados en Aura. El marco de trabajo LWC ofrece un mejor desempeño porque las funciones principales se implementan de forma nativa en motores web en vez de en JavaScript a través de abstracciones de marco de trabajo. Si no está familiarizado, dé una lectura [a esta publicación](https://developer.salesforce.com/blogs/2018/12/introducing-lightning-web-components.html).

En 2019, realizamos un [estudio de caso](https://developer.salesforce.com/blogs/2019/06/case-study-dreamhouse-gains-speed-by-switching-to-lwc.html) comparando el desempeño de la misma función en Aura frente a en LWC. Como resultado de la conversión de DreamHouse de Aura a LWC, la experiencia de desarrollo no solo estaba mucho más alineada con los estándares y patrones de desarrollo de front-end web actuales, sino que las ganancias de desempeño fueron significativas. Las mediciones de laboratorio mostraron ganancias en el intervalo del **2,4 al 24,7%** para caché en frío y ganancias en el intervalo del **31,83 al** **63,32%** para caché en caliente en las mismas dos páginas.

Ahora, ¿qué marco de trabajo están utilizando nuestras tecnologías de formularios? En otras palabras, ¿qué tecnologías de formularios se benefician de este desempeño superior?

- Formularios dinámicos, que está integrado en los metadatos de páginas Lightning, está construido sobre una base que utiliza la pila LWC, lo que nos permitirá implementar algunas funciones solicitadas desde hace tiempo. Como bonificación de desempeño, Formularios dinámicos utiliza la representación progresiva, que da como resultado un tiempo de carga de página mejorado para páginas que tienen un gran número de campos.
- Los flujos de pantalla se crean en LWC con la mayoría de los componentes individuales listos para su uso convertidos ahora a LWC con la excepción de dos componentes listos para su uso: Imagen y carga de archivos. Aunque el equipo de Flow convirtió el cliente de tiempo de ejecución de flujo a LWC, así como la mayoría de sus componentes, los clientes aún necesitan convertir sus componentes de pantalla Aura a LWC. No solo eso, sino que Salesforce solo admite componentes LWC en el nuevo marco de componentes reactivos en flujos de pantalla. Existe un excelente módulo Trailhead que explica cómo hacerlo: [Componentes web Lightning para desarrolladores Aura](https://trailhead.salesforce.com/en/content/learn/modules/lightning-web-components-for-aura-developers). Huelga decir que: Si está pensando en crear un componente personalizado para un flujo de pantalla o cualquier otro contenedor, vaya siempre a LWC.
- Existen algunas versiones de OmniStudio disponibles. Si es un cliente de larga data, es posible que esté utilizando Angular. Animamos a todos los nuevos clientes a comenzar con FlexCards y OmniScripts basados en LWC, y a los clientes existentes a migrar fuera de Angular.
- LWC se basa en ... LWC por supuesto. Esto es un regalo. 🤓

## Observaciones finales

Como arquitecto, es importante tener una comprensión sólida de todas las opciones disponibles para usted y cómo puede aplicarlas en su caso de uso específico. Para la creación de formularios en Salesforce, las opciones van desde código bajo (utilizando Formularios dinámicos en Lightning App Builder, Flujos de pantalla en Flow Builder y OmniScripts en OmniStudio) a código profesional (utilizando el marco de trabajo LWC), con una combinación de flujos de pantalla u OmniScripts y LWC en el medio. Tenga en cuenta esta guía y utilícela como referencia cuando esté planificando crear o rediseñar formularios en Salesforce. Si está buscando orientación sobre cómo diseñar formularios simplificados y útiles, consulte [Salesforce Well-Architected: Implicante](/docs/architect/es-mx/well-architected/guide/engaging).

### Dinos lo que piensas

Ayúdenos a asegurarnos de que estamos publicando lo más relevante para usted: [realice nuestra encuesta](https://forms.gle/FCFCES6vsRbKv4E29) para proporcionar comentarios sobre este contenido e indicarnos qué le gustaría ver a continuación.

<!-- document id=d148cf2c299c6787d149ac2497b91350e99fe2f054869d73816f917b3cf70e1a url=/architect/next/es-mx/decision-guides/guides/data-integration.md -->

## Descripción general de guía

Existen multitud de formas de acceder, sincronizar y compartir datos entre Salesforce y sistemas externos. Pero no todas las herramientas son adecuadas para su proyecto concreto. Esta guía le guiará por el panorama de las herramientas de integración de datos disponibles en Salesforce. También ofrece recomendaciones para las herramientas (o combinaciones de herramientas) más apropiadas en un caso de uso concreto, así como directrices sobre herramientas a evitar para escenarios específicos.

Esta guía de decisiones se centra en integraciones a nivel de datos que implican Salesforce. Específicamente, cubre los siguientes casos de uso de integración de datos:

- Salesforce en sistemas externos
- Sistemas externos en Salesforce
- Organización de Salesforce a organización de Salesforce

Estos son solo un subconjunto de los retos de integración a los que se enfrentan los arquitectos de Salesforce, por lo que planeamos agregar más guías de decisiones centradas en la integración dirigida por eventos, la creación de flujos de trabajo efectivos de cara al cliente o empleado utilizando la integración de procesos, etc. Finalmente, es importante tener en cuenta que muchas de las herramientas y enfoques descritos aquí se pueden utilizar para resolver retos de integración en la compañía en general, pero dichos usos están más allá del alcance de esta guía.

### Comida para llevar

- **Evite la replicación de datos innecesaria.** A menos que los datos necesiten residir en Salesforce, considere la virtualización de datos con Salesforce Connect en su lugar. Más datos en su organización llevan en última instancia a mayores volúmenes de datos, lo que puede afectar negativamente al [desempeño](/docs/architect/es-mx/well-architected/guide/reliable#desempeño) y agregar deuda técnica. Si sus datos ya residen en Salesforce y los necesita en un sistema externo, evite copiarlos en un sistema externo a menos que sea absolutamente necesario. En su lugar, haga que el sistema externo acceda a los datos a través de las API de Salesforce.
- **Utilice MuleSoft u otras soluciones de Enterprise Service Bus (ESB) o Extract-Transform-Load (ETL), si están disponibles y forman parte de su panorama existente.** Debido a que estas herramientas están creadas para ayudar a dar cobertura a la migración y transformación de datos, a menudo tienen potentes funciones que le permiten reutilizar integraciones en toda la compañía, mantener una gobernanza más sólida y centralizar la gestión de integraciones. En esta guía, siempre que se recomiende MuleSoft Anypoint, considere si su solución ESB/ETL existente será suficiente.
- **Armonice datos de diferentes orígenes con Data 360 y Data Cloud One.** A través del modelo de datos Customer 360, la resolución de identidad, la federación de datos y otras funciones, Data 360 consolida datos de Salesforce y otros sistemas externos en una vista unificada de su cliente. Además, con [Data Cloud One](/docs/architect/es-mx/fundamentals/guide/data360_integration_patterns_and_practices.html#unified-multi-org-data-platform-with-data-cloud-one), los usuarios de otras organizaciones de Salesforce pueden acceder de forma segura a datos compartidos virtualmente desde Data 360 a través de espacios de datos.
- Mueva datos entre organizaciones utilizando activaciones y acciones de **Data 360.** Después de ingresar datos desde diferentes organizaciones en Data 360, las [acciones y activaciones](/docs/architect/es-mx/fundamentals/guide/data360_integration_patterns_and_practices.html#data-activation-patterns--data-outbound) de datos pueden sincronizar los datos con otra organización. Este enfoque puede ser muy útil para integraciones con organizaciones de Marketing Cloud.
- Extraiga y mueva datos utilizando **MuleSoft Anypoint.** MuleSoft Anypoint se puede utilizar para extraer datos de Data 360 utilizando API de Connect y API de gráfico de datos y moverlos a otra organización de Salesforce. Sin Data 360, MuleSoft Anypoint también se puede utilizar cuando los datos necesitan moverse entre organizaciones sin replicarse en Data 360.
- **Tenga cuidado si elige construir con Mensajería saliente.** Salesforce seguirá admitiendo Mensajería saliente dentro de las capacidades funcionales actuales, pero no tiene intención de realizar más inversiones en esta tecnología.
- **Siempre se recomienda la licencia de usuario de integración con perfil "Solo API" para todas las integraciones.** Salesforce también recomienda utilizar Aplicaciones cliente externas (a favor de aplicaciones conectadas o inicio de sesión SOAP) como los patrones AuthN y AuthZ permitidos correctamente para todas las integraciones.

## Consideraciones comunes para la selección de herramientas de integración de datos

Antes de profundizar en las herramientas de integración de datos disponibles, es importante tener en cuenta algunas consideraciones comunes al elegir una herramienta. Como es típico con la arquitectura, no hay una respuesta prescriptiva a cada reto de negocio. Si pronunció las palabras “depende” al realizar opciones de integración, estará en el lugar correcto.

<table>
    <thead>
        <tr>
            <th>Área a tener en cuenta</th>
            <th>Preguntas comunes</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>Herramientas y panorama existentes</td>
            <td>¿Existe una solución ESB o ETL existente? ¿Tienen los datos implicados requisitos normativos o de cumplimiento? ¿Dónde están ubicados los sistemas que está intentando integrar (en la nube o in situ)?</td>
        </tr>
        <tr>
            <td>Flujo de datos (Cronología, Experiencia de usuario prevista, Dirección)</td>
            <td>¿Necesitan los datos moverse de forma síncrona, asíncrona o pueden ser por lotes/programados? ¿Se requiere replicación de datos? ¿Qué sistema debe ser la fuente de la verdad? ¿Cuál es el origen de datos? ¿Cuál es el destino de destino? ¿Se requiere la interacción del usuario? ¿Necesita el usuario ver el resultado de la integración? ¿Cuáles son las necesidades sobre la gestión de excepciones (reintentar, notificar, fallar)? ¿Qué grado de acoplamiento deben tener los sistemas?</td>
        </tr>
        <tr>
            <td>Implementación</td>
            <td>¿Cuál es el nivel de esfuerzo para sistemas que no son de Salesforce? ¿Qué equipos son responsables de entregar integraciones? ¿Qué herramientas prefieren utilizar?</td>
        </tr>
        <tr>
            <td><a href="/docs/architect/es-mx/well-architected/guide/intentional#mantenibilidad">Mantenibilidad</a></td>
            <td>¿Qué equipos se espera que mantengan la integración? ¿Qué habilidades tienen actualmente? ¿Qué habilidades necesitarán en el futuro? ¿Cuál es el costo total de propiedad a lo largo del tiempo? ¿Qué importancia tiene la capacidad de probar, depurar y solucionar problemas con herramientas de código bajo o profesional?</td>
        </tr>
        <tr>
            <td><a href="/docs/architect/es-mx/well-architected/guide/reliable#volumen-de-datos">Volumen de datos</a></td>
            <td>¿Cuántos datos están implicados en la integración? ¿Trabajará con <a href="https://trailhead.salesforce.com/content/learn/modules/large-data-volumes">grandes volúmenes de</a> datos (LDV)? ¿Con qué frecuencia se producirán cambios de forma masiva? ¿Qué tipo de repercusión tendrán las actualizaciones singleton? ¿Con qué frecuencia se producirán?</td>
        </tr>
        <tr>
            <td>Límites</td>
            <td>¿Necesitarán los datos someterse a una transformación compleja? ¿Necesitan combinarse los datos desde varios sistemas de origen? ¿Con qué frecuencia se realizará una integración por usuario? ¿Cuántos usuarios en total? ¿Planificó con antelación cargas de datos masivas (ejemplo: carga de datos inicial para una nueva instancia)?</td>
        </tr>
    </tbody>
</table>

## Comparación de productos

Esta es una descripción general de alto nivel de las herramientas disponibles para la integración de datos y algunas consideraciones para empezar a evaluar cada opción. Las siguientes secciones incluyen casos de uso detallados y detalles sobre las funciones de estas herramientas.

<table>
    <thead>
        <tr>
            <th></th>
            <th>De Salesforce a Sistema externo</th>
            <th>Del sistema externo a Salesforce</th>
            <th>Ejecución</th>
            <th>Se requiere licencia adicional</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Acciones Apex</strong></td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Del lado del servidor</td>
            <td>No</td>
        </tr>
        <tr>
            <td><strong>Captura de datos</strong></td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-no">No disponible</td>
            <td class="guide-table-ok">Del lado del servidor</td>
            <td>No*</td>
        </tr>
        <tr>
            <td><strong>Apex personalizado (servicios web REST y SOAP)</strong></td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Del lado del servidor</td>
            <td>No</td>
        </tr>
        <tr>
            <td><strong>Servicios externos</strong></td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-no">No disponible</td>
            <td class="guide-table-ok">Del lado del servidor</td>
            <td>No</td>
        </tr>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Del lado del servidor</td>
            <td>Sí</td>
        </tr>
        <tr>
            <td><strong>Data 360</strong></td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Del lado del servidor</td>
            <td>Sí</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Del lado del servidor</td>
            <td>Sí</td>
        </tr>
        <tr>
            <td><strong>API nativas de Salesforce</strong></td>
            <td class="guide-table-no">No disponible</td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Del lado del servidor</td>
            <td>No</td>
        </tr>
        <tr>
            <td><strong>OmniScript</strong></td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-no">Del lado del cliente***</td>
            <td>Sí</td>
        </tr>
        <tr>
            <td><strong>Procedimiento de integración de OmniStudio</strong></td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Del lado del servidor</td>
            <td>Sí</td>
        </tr>
        <tr>
            <td><strong>Mensajería saliente</strong></td>
            <td>No es ideal</td>
            <td class="guide-table-no">No disponible</td>
            <td class="guide-table-ok">Del lado del servidor</td>
            <td>No</td>
        </tr>
        <tr>
            <td><strong>Eventos de plataforma</strong></td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Del lado del servidor</td>
            <td>No**</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect / Objetos externos</strong></td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Disponible</td>
            <td class="guide-table-ok">Del lado del servidor</td>
            <td>Sí</td>
        </tr>
    </tbody>
</table>

[\*Complemento requerido para casos de uso de eventos de Captura de datos de cambios de gran volumen](https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_allocations.htm)

[\*\*Complemento requerido para casos de uso de eventos de plataforma de gran volumen](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm)

\*\*\*Adecuado en situaciones donde está bien que la lógica de negocio se ejecute en el navegador web.

Leyenda de columna:

- **Disponible**: funciona bien para la mayoría de los casos de uso
- **No es ideal**: posible pero considere una herramienta alternativa
- **No disponible**: no hay planes de asistencia en los próximos doce meses

### Otras herramientas que pueden estar implicadas en el traslado de datos dentro y fuera de Salesforce:

Existen otras herramientas que pueden admitir algunos aspectos de la integración de una capa de datos, pero no deben considerarse un medio principal para resolver problemas de integración. Echemos un vistazo rápido a estas herramientas ahora.

Los **componentes web Lightning** se utilizan habitualmente para integraciones de procesos, pero pueden realizar llamadas utilizando funciones JavaScript, de modo que los datos podrían estar implicados en estas transacciones.

**Salesforce Flow** se puede utilizar para orquestar llamadas externas con Servicios externos o Acciones Apex. Salesforce Flow por sí mismo no se considera una herramienta de integración de datos independiente.

El Asistente de importación de **datos y el Cargador** de datos se pueden utilizar para sincronizar, importar y migrar datos. Aunque los comandos del Cargador de datos también se pueden crear secuencias de comandos para automatizar la importación y exportación de datos, la [interfaz de línea](https://developer.salesforce.com/docs/atlas.en-us.dataLoader.meta/dataLoader/command_line_intro.htm) de comandos es solo para Windows y ninguna de estas herramientas es una base recomendada para una estrategia de integración de datos. En su lugar, utilícelos para complementar su estrategia de mantenimiento y administración de datos.

Los comandos de datos [**Salesforce CLI**](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_data.htm) se pueden utilizar para manipular registros en su organización. Los comandos están disponibles para ayudarle a importar y exportar datos con la API masiva y la API de guardado de árboles de SObject, y realizar operaciones CRUD sencillas en registros individuales con la API de REST. Salesforce CLI por sí misma no se considera una herramienta de integración de datos independiente.

**OmniStudio Data Mapper** se puede utilizar como una herramienta ETL declarativa para mover datos entre objetos de Salesforce y estructuras de datos JSON. Aunque se crea automáticamente una interfaz de REST para cada interfaz de Asignador de datos, proporcionando una forma declarativa de mover datos desde sistemas externos a objetos de Salesforce, Asignador de datos independiente no es una base recomendada para una estrategia de integración de datos. Las acciones de Asignador de datos están disponibles en Procedimientos de integración de OmniStudio.

[**Dataloader.io**](http://dataloader.io/) es otra herramienta de carga de datos para Salesforce con tecnología Anypoint Platform de MuleSoft que le permite importar, exportar y eliminar cantidades ilimitadas de datos para su compañía de forma rápida y segura. Dataloader.io no es una base recomendada para una estrategia de integración de datos.

## Salesforce en sistemas externos (Integración saliente)

Para integraciones salientes desde Salesforce, puede considerar diferentes tipos de herramientas: de código bajo, procódigo o híbridas. Las siguientes secciones proporcionan orientación para cada uno de estos tipos de herramientas y ofrecen soluciones de muestra.

- [Herramientas de bajo código para integraciones salientes](#herramientas-de-código-bajo-para-integraciones-salientes-desde-salesforce)
- [Herramientas híbridas para integraciones salientes](#herramientas-híbridas-para-integraciones-salientes-desde-salesforce)
- [Herramientas de código profesional para integraciones salientes](#herramientas-de-procódigo-para-integraciones-salientes-desde-salesforce)

### Herramientas de código bajo para integraciones salientes desde Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Directrices</th>
            <th>Licencia</th>
            <th>Cronología</th>
            <th>Volumen y escala</th>
            <th></th>
            <th>Entrega y mantenimiento</th>
            <th></th>
            <th></th>
            <th>Privacidad y seguridad</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th><strong>Cuándo utilizar</strong></th>
            <th><strong>Licencia adicional</strong></th>
            <th><strong>Sincronizar (Solicitud/Respuesta) o Asíncronizar (Fuego/Olvido)</strong></th>
            <th><strong>Compatibilidad con múltiples objetos</strong></th>
            <th><strong>LDV/masa</strong></th>
            <th><strong>Pruebas e implementación**</strong></th>
            <th><strong>Depuración</strong></th>
            <th><strong>Comportamiento de reintento/gestión de errores integrado</strong></th>
            <th><strong>Puede utilizar con datos cifrados en periodos de inactividad</strong></th>
            <th><strong>Protocolo de autenticación</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Captura de datos</strong></td>
            <td>Cuando necesita publicar cambios a nivel de registro realizados en Salesforce en un sistema externo y no necesita una carga personalizada.</td>
            <td>Requerido</td>
            <td>Async</td>
            <td>No</td>
            <td>No</td>
            <td class="guide-table-ok">Sí</td>
            <td>Con herramientas de procódigo</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Servicios externos</strong></td>
            <td>Cuando está orquestando un proceso utilizando Flow, Apex, Einstein Bots u OmniStudio y las API del sistema externo se describen utilizando especificaciones de OpenAPI.</td>
            <td>No se requiere</td>
            <td>Sync</td>
            <td class="guide-table-ok">Sí</td>
            <td>No</td>
            <td class="guide-table-ok">Sí</td>
            <td>Con herramientas de procódigo</td>
            <td>No</td>
            <td>N/A</td>
            <td>Credenciales nombradas</td>
        </tr>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td>Cuando desea ampliar sus datos con sincronización bidireccional para activar aplicaciones móviles y otras en Heroku, y desea que los datos también se repliquen en Salesforce.</td>
            <td>Requerido</td>
            <td>Async</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>No</td>
            <td>Con herramientas de código profesional</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí, a través de Shield Connect</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Procedimiento de integración de OmniStudio</strong></td>
            <td>Cuando necesita transformar datos sin interacción del usuario y mejorar el desempeño procesando en el servidor en vez del navegador.</td>
            <td>Requerido</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>Compatibilidad declarativa</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>Credenciales nombradas</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect / Objetos externos</strong></td>
            <td>Cuando desea que los datos aparezcan en la interfaz de usuario de Salesforce, pero desea que los datos se almacenen en un sistema externo. Los datos no se replican en Salesforce.</td>
            <td>Requerido</td>
            <td>Sync</td>
            <td>No</td>
            <td class="guide-table-ok">Sí*</td>
            <td class="guide-table-ok">Sí</td>
            <td>Con herramientas de procódigo y un trazador declarativo</td>
            <td>No</td>
            <td>N/A</td>
            <td>Credenciales nombradas</td>
        </tr>
        <tr>
            <td colspan="11">*Los adaptadores Odata anteriores a la versión 4.01 están sujetos a límites de llamadas. Consulte <a href="https://help.salesforce.com/s/articleView?id=platform.odata_general_limits.htm&type=5">Consideraciones sobre límites</a> de frecuencia de llamadas Odata para obtener más detalles. ** Pruebas e implementación hace referencia a la capacidad de crear en un entorno inferior e implementar a través de la <a href="https://developer.salesforce.com/docs/metadata-coverage/">API de metadatos</a>, paquetes o conjuntos de cambios en producción.</td>
        </tr>
    </tbody>
</table>

### Caso de uso: Integración saliente utilizando herramientas de código bajo

> Cuando se ganan oportunidades, se debe crear un pedido para los productos asociados en el sistema ERP o el sistema de gestión de pedidos de la compañía.

**Captura de datos** Conforme se actualizan los registros de oportunidades, Captura de datos cambia publica eventos de cambio que contienen las actualizaciones de los objetos. Los eventos de cambio se consumen en el lado del cliente a través de una conexión CometD (o a través de un conector MuleSoft) y se utilizan para actualizar el sistema ERP o de gestión de pedidos del cliente. Los eventos de cambio pueden enriquecerse para incluir siempre Id. de registro externos u otros datos del objeto (como región) que se necesitan para la integración. Las transmisiones de eventos de cambio para múltiples objetos se pueden combinar en _canales_ para una suscripción simplificada y procesamiento de transmisiones (de modo que puede suscribirse y procesar una transmisión en vez de muchas).

**Servicios externos** Si tiene un servicio web que admite la especificación OpenAPI 2.0 o 3.0, puede exponer las operaciones y los servicios como un Servicio externo en Salesforce. Las operaciones de API (por ejemplo, crear orden) se pueden llamar como una Acción invocable en un flujo creado con Flow Builder cuando la etapa de la oportunidad cambia a "Ganada".

**Heroku Connect** Heroku Connect se utiliza habitualmente para mantener una base de datos Postgres de Heroku y Salesforce sincronizadas. Si el cliente utiliza Heroku Postgres como su establecimiento de transacciones de origen de verdad, puede sincronizar los registros y los cambios de Salesforce a Heroku Postgres utilizando Heroku Connect. Desde allí, puede utilizar Conectores de transmisión de Heroku para publicar esos cambios en Apache Kafka y enviarlos como eventos a aplicaciones descendentes, incluyendo el sistema ERP o de gestión de pedidos.

**Procedimiento de integración** de OmniStudio Cuando se envía un pedido, el OmniScript que orquesta el proceso puede publicar los detalles del pedido en un conector ERP o MuleSoft. La publicación puede ejecutarse directamente por OmniScript (lado del cliente) o indirectamente a través de un Procedimiento de integración (lado del servidor). Si el sistema ERP arroja un error de validación, la interfaz de usuario de OmniScript debe notificar al usuario y, si es necesario, traducir y contextualizar el error para el usuario.

**Salesforce Connect / Objetos externos** Puede crear un flujo desencadenado por registro en Salesforce que inserta un registro en los objetos externos relacionados cuando la etapa de la oportunidad cambia a "Ganada". Puesto que se trata de una [transacción mixta](https://help.salesforce.com/articleView?id=000328873&type=1&mode=1), para evitar errores, agregue un elemento de pausa durante cero segundos entre la actualización Oportunidad y los insertos de objetos externos relacionados de modo que cierre un contexto de transacción antes de iniciar uno nuevo.

### Herramientas híbridas para integraciones salientes desde Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Directrices</th>
            <th>Licencia</th>
            <th>Cronología</th>
            <th>Volumen y escala</th>
            <th></th>
            <th>Entrega y mantenimiento</th>
            <th></th>
            <th></th>
            <th>Privacidad y seguridad</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th><strong>Cuándo utilizar</strong></th>
            <th><strong>Licencia adicional</strong></th>
            <th><strong>Sincronizar (Solicitud/Respuesta) o Asíncronizar (Fuego/Olvido)</strong></th>
            <th><strong>Compatibilidad con múltiples objetos</strong></th>
            <th><strong>LDV/masa</strong></th>
            <th><strong>Pruebas e implementación**</strong></th>
            <th><strong>Depuración</strong></th>
            <th><strong>Comportamiento de reintento/gestión de errores integrado</strong></th>
            <th><strong>Puede utilizar con datos cifrados en periodos de inactividad</strong></th>
            <th><strong>Protocolo de autenticación</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Acciones Apex</strong></td>
            <td>Cuando desea automatizar llamadas a otro sistema a través de Salesforce Flow. Un desarrollador puede redactar una clase Apex que un flujo puede invocar, o puede descargar una solución preconstruida desde AppExchange.</td>
            <td>No se requiere</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sí</td>
            <td>No</td>
            <td class="guide-table-ok">Sí</td>
            <td>Con herramientas de procódigo</td>
            <td>No</td>
            <td class="guide-table-ok">Sí</td>
            <td>Múltiples</td>
        </tr>
        <tr>
            <td><strong>Retransmisiones de eventos</strong></td>
            <td>Cuando necesite enviar eventos de plataforma y eventos de Captura de datos de cambios a Amazon EventBridge desde Salesforce. Las retransmisiones de eventos solo se conectan a AWS Eventbridge</td>
            <td>No</td>
            <td>Async</td>
            <td class="guide-table-ok">Sí</td>
            <td>No</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>HTTP/1.1 con TLS</td>
        </tr>
        <tr>
            <td><strong>Mensajería saliente</strong></td>
            <td>Cuando necesita enviar mensajes SOAP a través de HTTP(S) a un extremo designado con recepción garantizada cuando se desencadena por una regla de flujo de trabajo.</td>
            <td>No se requiere</td>
            <td>Async</td>
            <td>No</td>
            <td>No</td>
            <td class="guide-table-ok">Sí</td>
            <td>Compatibilidad declarativa</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>TLS bidireccional</td>
        </tr>
        <tr>
            <td><strong>Eventos de plataforma</strong></td>
            <td>Cuando necesita una carga estructurada definida personalizada para cambios casi en tiempo real en Salesforce o un sistema externo.</td>
            <td>No requerido*</td>
            <td>Async</td>
            <td class="guide-table-ok">Sí</td>
            <td>No</td>
            <td class="guide-table-ok">Sí</td>
            <td>Con herramientas de procódigo</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect / Objetos externos (con adaptadores Apex personalizados)</strong></td>
            <td>Cuando desea que los datos aparezcan en la interfaz de usuario de Salesforce, pero desea que los datos se almacenen en un sistema externo que no puede utilizar protocolos estándar como Odata o GraphQL.</td>
            <td>Requerido</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>Con herramientas de procódigo</td>
            <td>No</td>
            <td>N/A</td>
            <td>Múltiples</td>
        </tr>
         <tr>
            <td><strong>Data 360</strong></td>
            <td>Cuando desea datos armonizados desde diferentes orígenes en un solo establecimiento de datos, o desea replicar sus datos en otras organizaciones de Salesforce o en otros sistemas externos.</td>
            <td>Requerido</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>Múltiples</td>
        </tr>
    </tbody>
</table>

[\*Complemento](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) requerido para casos de uso de gran volumen.

\*\*Pruebas e implementación hace referencia a la capacidad de construir en un entorno inferior e implementar a través de la [API de metadatos](https://developer.salesforce.com/docs/metadata-coverage/), paquetes o conjuntos de cambios en producción.

### Caso de uso: Integración saliente utilizando herramientas híbridas

> Cuando se ganan oportunidades, se debe crear un pedido para los productos asociados en el sistema ERP o de gestión de pedidos de la compañía.

**Acciones Apex** Un flujo desencadenado por registro basado en el estado de la oportunidad puede desencadenarse automáticamente cuando se gana una oportunidad. El flujo ejecuta una acción invocable que utiliza una llamada externa para enviar el pedido al sistema de gestión de pedidos o la solución ERP. Los envíos de gran volumen y los pedidos de múltiples sitios se gestionan mediante mecanismos de cola y lotes Apex.

**Mensajería saliente** Tras [configurar la mensajería](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging_setting_up.htm) saliente, puede definir una regla de flujo de trabajo desencadenada por la actualización de oportunidad para enviar un mensaje SOAP a través de HTTP(S) a una URL de extremo especificada que aloja al oyente. El mensaje contendrá los campos especificados cuando se creó el mensaje saliente. Si la información del objeto cambia después de poner la notificación en cola, pero antes de enviarse, solo se entregará la información actualizada y los mensajes permanecerán en la cola hasta que se envíen correctamente o hasta que tengan 24 horas de antigüedad. Transcurridas 24 horas, los mensajes se eliminan de la cola. Si el sistema ERP requiere datos adicionales, puede pasar el sessionId en mensajes salientes de modo que el sistema externo pueda realizar una solicitud de devolución de llamada.

**Eventos de plataforma** Puede definir un evento de plataforma que incluya la carga personalizada con los datos requeridos para crear los registros en el sistema externo. Como los eventos de plataforma no se publican automáticamente tras el cambio de registro, debe publicar el evento mediante Apex, Salesforce Flow o Process Builder cuando la etapa de la oportunidad cambia a "Ganada". Un servicio externo escucha el canal de eventos de plataforma utilizando CometD (o un conector MuleSoft) y crea los registros apropiados en el sistema externo.

**Salesforce Connect / Objetos externos (con adaptadores Apex personalizados)** Una solución basada en Salesforce Connect / Objetos externos no es perfecta para un caso de uso que requiere puramente sincronización de datos. Sin embargo, esta solución puede aplicarse en casos donde los usuarios de Salesforce necesitan ver y posiblemente interactuar con datos del sistema externo, y los datos no pueden replicarse en Salesforce. Si el sistema ERP o de gestión de pedidos no admite protocolos Odata o GraphQL, el equipo de desarrollo puede utilizar el [Marco de trabajo](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_connector_start.htm) del conector Apex para redactar clases Apex que gestionan la comunicación con el sistema externo a través de un protocolo compatible.

**Data 360** Una solución basada en Data 360 es perfecta para casos de uso donde necesitamos datos armonizados de diferentes orígenes en un solo almacén de datos. También se puede utilizar cuando necesitamos replicar datos desde una organización de Salesforce en múltiples organizaciones de Salesforce u otros sistemas externos utilizando Data 360 como un núcleo de datos. Cuando se gana y se actualiza una oportunidad en la organización de origen, los datos de la oportunidad se sincronizarán con Data 360, donde se pueden replicar en otros sistemas incluyendo organizaciones de Salesforce utilizando diferentes mecanismos como acciones, activaciones y API. Del mismo modo, se puede hacer referencia a una oportunidad sin replicar los datos en otras organizaciones de Salesforce utilizando Data Cloud One. Sin embargo, Data Cloud One no admite plataformas que no sean de Salesforce.

### Herramientas de procódigo para integraciones salientes desde Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Directrices</th>
            <th>Licencia</th>
            <th>Cronología</th>
            <th>Volumen y escala</th>
            <th></th>
            <th>Entrega y mantenimiento</th>
            <th></th>
            <th></th>
            <th>Privacidad y seguridad</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th><strong>Cuándo utilizar</strong></th>
            <th><strong>Licencia adicional</strong></th>
            <th><strong>Sincronizar (Solicitud/Respuesta) o Asíncronizar (Fuego/Olvido)</strong></th>
            <th><strong>Compatibilidad con múltiples objetos</strong></th>
            <th><strong>LDV/masa</strong></th>
            <th><strong>Pruebas e implementación**</strong></th>
            <th><strong>Depuración</strong></th>
            <th><strong>Comportamiento de reintento/gestión de errores integrado</strong></th>
            <th><strong>Puede utilizar con datos cifrados en periodos de inactividad</strong></th>
            <th><strong>Protocolo de autenticación</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Apex personalizado</strong></td>
            <td>Cuando necesita más funciones de las disponibles en herramientas de código bajo.</td>
            <td>No se requiere</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>Con herramientas de procódigo</td>
            <td>No</td>
            <td class="guide-table-ok">Sí*</td>
            <td>Múltiples</td>
        </tr>
        <tr>
            <td><strong>Servicios externos</strong></td>
            <td>La integración desde código con API del sistema externas se describe utilizando especificaciones de OpenAPI.</td>
            <td>No se requiere</td>
            <td>Sync</td>
            <td class="guide-table-ok">Sí</td>
            <td>No</td>
            <td class="guide-table-ok">Sí</td>
            <td>Con herramientas de procódigo</td>
            <td>No</td>
            <td>N/A</td>
            <td>Múltiples</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td>Cuando necesita una única solución unificada de nivel de compañía para crear, orquestar y gestionar sus integraciones; cuando necesita sustituir una arquitectura de punto a punto heredada; o cuando necesita asistencia de gestión de API.</td>
            <td>Requerido</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>Con herramientas de procódigo</td>
            <td>No</td>
            <td class="guide-table-ok">Sí*</td>
            <td>Múltiples</td>
        </tr>
    </tbody>
</table>

\*La activación Shield Platform Encryption cambia ciertos comportamientos, consulte [Consideraciones generales Shield Platform Encryption](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5) para obtener más detalles.

\*\*Pruebas e implementación hace referencia a la capacidad de construir en un entorno inferior e implementar a través de la [API de metadatos](https://developer.salesforce.com/docs/metadata-coverage/), paquetes o conjuntos de cambios en producción.

### Caso de uso: Integración saliente utilizando herramientas de código profesional

> Cuando se ganan oportunidades, se debe crear un pedido para los productos asociados en el sistema ERP o de gestión de pedidos de la compañía.

**Apex personalizado** Puede crear un desencadenador Apex y un controlador o controladores de desencadenador en la Oportunidad que realizan una llamada al sistema ERP o de gestión de pedidos cuando la etapa de la oportunidad cambia a "Ganada". Tenga en cuenta que si realiza llamadas desde un desencadenador o después de realizar una operación DML, debe utilizar un método anotado como futuro o colocable en cola. Una llamada en un desencadenador mantiene la conexión de la base de datos abierta durante el tiempo de vida de la llamada. Todo el código Apex está vinculado por [Apex Governor y API Limits](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_overview.htm), que se revisan de forma continua.

**Servicios externos** Si el sistema ERP externo de la compañía o el sistema de gestión de pedidos se definen a través de una especificación OpenAPI, las llamadas a esos servicios que se realizan en el método futuro o el trabajo colocable en cola podrían simplificarse. Los servicios externos registrados se pueden llamar directamente desde Apex sin necesidad de escribir código de placa de caldera. En el ejemplo, la llamada para crear el pedido puede gestionarse por el servicio externo.

**MuleSoft Anypoint** MuleSoft Anypoint proporciona gestión de API de nivel de compañía. MuleSoft Anypoint puede crear API para permitir el acceso de lectura (y/o escritura) a datos para Salesforce y muchos otros sistemas de negocio. Hay [muchos conectores preintegrados disponibles](https://www.mulesoft.com/platform/cloud-connectors) para simplificar la implementación, y las compañías pueden crear y publicar sus propios conectores también. Estas API se pueden implementar en Anypoint con políticas de seguridad flexibles, que admiten la gestión y la gobernanza centralizadas. No hay restricciones en el volumen de transacciones, siempre que la API tenga el tamaño adecuado para su utilización máxima (medida en vCores).

## Datos de sistemas externos en Salesforce (Integración entrante)

Para integraciones entrantes en Salesforce, puede considerar diferentes tipos de herramientas: de código bajo, procódigo o híbridas. Las siguientes secciones proporcionan orientación para cada uno de estos tipos de herramientas y ofrecen soluciones de muestra.

- [Herramientas de bajo código para integraciones entrantes](#herramientas-de-código-bajo-para-integraciones-entrantes-en-salesforce)
- [Herramientas híbridas para integraciones entrantes](#herramientas-híbridas-para-integraciones-entrantes-en-salesforce)
- [Herramientas de código profesional para integraciones entrantes](#herramientas-de-procódigo-para-integraciones-entrantes-en-salesforce)

### Herramientas de código bajo para integraciones entrantes en Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Directrices</th>
            <th>Licencia</th>
            <th>Cronología</th>
            <th>Volumen y escala</th>
            <th></th>
            <th>Entrega y mantenimiento</th>
            <th></th>
            <th></th>
            <th>Privacidad y seguridad</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th>Cuándo utilizar</th>
            <th>Licencia adicional</th>
            <th>Sincronizar (Solicitud/Respuesta) o Asíncronizar (Fuego/Olvido)</th>
            <th>Compatibilidad con múltiples objetos</th>
            <th>LDV/masa</th>
            <th>Pruebas e implementación*</th>
            <th>Depuración</th>
            <th>Comportamiento de reintento/gestión de errores integrado</th>
            <th>Puede utilizar con datos cifrados en periodos de inactividad</th>
            <th>Protocolo de autenticación</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td>Cuando desea ampliar sus datos con sincronización bidireccional para activar aplicaciones móviles y otras en Heroku, y desea que los datos también se repliquen en Salesforce.</td>
            <td>Requerido</td>
            <td>Async</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>No</td>
            <td>Con herramientas de procódigo</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí, a través de Shield Connect</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Procedimiento de integración de OmniStudio</strong></td>
            <td>Cuando necesita importar y transformar datos desde fuentes externas sin interacción del usuario.</td>
            <td>Requerido</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>Compatibilidad declarativa</td>
            <td>No</td>
            <td class="guide-table-ok">Sí</td>
            <td>Credenciales nombradas</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect / Objetos externos</strong></td>
            <td>Cuando desea que los datos aparezcan en la interfaz de usuario de Salesforce, pero desea que los datos se almacenen en un sistema externo que pueda utilizar protocolos estándar como Odata o GraphQL.</td>
            <td>Requerido</td>
            <td>Sync</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>Con herramientas de procódigo</td>
            <td>No</td>
            <td>N/A</td>
            <td>Múltiples</td>
        </tr>
    </tbody>
</table>

\*Pruebas e implementación hace referencia a la capacidad de construir en un entorno inferior e implementar a través de la [API de metadatos](https://developer.salesforce.com/docs/metadata-coverage/), paquetes o conjuntos de cambios en producción.

### Caso de uso: Integración entrante utilizando herramientas de código bajo

> Un contacto se actualiza en el sistema ERP de la organización. Esta información de contacto debe actualizarse en Salesforce.

**Heroku Connect** Heroku Connect se utiliza habitualmente para mantener una base de datos Postgres de Heroku y Salesforce sincronizadas. A menos que el sistema ERP utilice Postgres de Heroku como su almacén de transacciones, este caso de uso no es posible. Si utiliza Postgres de Heroku, los cambios realizados en las tablas Postgres se pueden sincronizar con objetos en Salesforce utilizando Heroku Connect.

**Procedimiento de integración** de OmniStudio Después de que el sistema ERP actualice el registro de contacto, se puede llamar a un procedimiento de integración de OmniStudio con una acción de carga de asignador de datos y una acción de respuesta a través de la API de REST generada por el asignador de datos. En primer lugar, una acción Carga de asignador de datos envía una carga JSON o XML, que se utiliza para alterar los registros de contacto basándose en un campo Id. externo o a través de una [Clave de inserción](https://trailhead.salesforce.com/content/learn/modules/omnistudio-data-tools-and-internal-data/build-an-integration-procedure-with-conditional-dataraptor-loads?trail_id=build-guided-experiences-with-omnistudio). Si una respuesta sencilla en JSON es todo lo que se espera, una Acción de respuesta puede enviar cualquier información relevante desde las acciones anteriores para indicar éxito o fallo. Si el sistema ERP espera una respuesta específica, se puede utilizar una transformación de asignador de datos o una acción de extracción para generar una respuesta JSON o XML con funciones adicionales para incluir declarativamente datos que se generaron en desencadenadores por la actualización de registro de contacto. El principal reto con este escenario es la concurrencia: Múltiples llamadas para actualizar el mismo registro de contacto de forma simultánea provocarán problemas ya que la API existe directamente en Salesforce.

**Salesforce Connect / Objetos externos** Salesforce Connect y los objetos externos no se recomiendan para este caso de uso, porque el escenario requiere específicamente la replicación de datos en Salesforce. Si tiene una integración Salesforce Connect preexistente construida en el sistema ERP, puede configurar el conector Odata 4.0 para admitir Captura de datos de cambios externos si el sistema ERP puede admitir Captura de datos de cambios. Además, debe configurar en Salesforce para suscribirse a la transmisión de cambios desde el sistema ERP, utilizando la API Pub/Sub.

### Herramientas híbridas para integraciones entrantes en Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Directrices</th>
            <th>Licencia</th>
            <th>Cronología</th>
            <th>Volumen y escala</th>
            <th></th>
            <th>Entrega y mantenimiento</th>
            <th></th>
            <th></th>
            <th>Privacidad y seguridad</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th>Cuándo utilizar</th>
            <th>Licencia adicional</th>
            <th>Sincronizar (Solicitud/Respuesta) o Asíncronizar (Fuego/Olvido)</th>
            <th>Compatibilidad con múltiples objetos</th>
            <th>LDV/masa</th>
            <th>Pruebas e implementación**</th>
            <th>Depuración</th>
            <th>Comportamiento de reintento/gestión de errores integrado</th>
            <th>Puede utilizar con datos cifrados en periodos de inactividad</th>
            <th>Protocolo de autenticación</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Eventos de plataforma</strong></td>
            <td>Cuando necesita una carga estructurada definida personalizada para cambios casi en tiempo real en Salesforce o un sistema externo.</td>
            <td>No requerido*</td>
            <td>Async</td>
            <td class="guide-table-ok">Sí</td>
            <td>No</td>
            <td class="guide-table-ok">Sí</td>
            <td>Con herramientas de procódigo</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect / Objetos externos (con adaptadores Apex personalizados)</strong></td>
            <td>Cuando necesita que los datos aparezcan en la interfaz de usuario de Salesforce, pero desea que los datos se almacenen en un sistema externo que no puede utilizar protocolos Odata 2.0/4.0.</td>
            <td>Requerido</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>Con herramientas de procódigo</td>
            <td>No</td>
            <td>N/A</td>
            <td>Múltiples</td>
        </tr>
        <tr>
            <td><strong>Data 360</strong></td>
            <td>Cuando desea datos armonizados desde diferentes orígenes en un solo establecimiento de datos, o desea replicar sus datos desde otras organizaciones de Salesforce o en otros sistemas externos. Data 360 también admite la virtualización para algunas plataformas.</td>
            <td>Requerido</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>No</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>Múltiples</td>
        </tr>
    </tbody>
</table>

\*Se requiere [un complemento](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) para casos de uso de gran volumen.

\*\*Pruebas e implementación hace referencia a la capacidad de construir en un entorno inferior e implementar a través de la [API de metadatos](https://developer.salesforce.com/docs/metadata-coverage/), paquetes o conjuntos de cambios en producción.

### Caso de uso: Integración entrante utilizando herramientas híbridas

> Un contacto se actualiza en el sistema ERP de la organización. Esta información de contacto debe actualizarse en Salesforce.

**Eventos de plataforma** El código personalizado en un sistema externo publica un Evento de plataforma cuando se actualiza el registro de contacto en el sistema ERP. Un desencadenador, Proceso o Flujo en Salesforce puede suscribirse al evento de plataforma y actualizar los objetos de Salesforce correspondientes cuando se procesa un evento. El Evento de plataforma puede funcionar simplemente como una señal de que se produjo un cambio en el sistema ERP del cliente sin incluir ningún dato, o puede contener los datos reales necesarios para actualizar el objeto de Salesforce.

**Salesforce Connect / Objetos externos (con adaptadores Apex personalizados)** Esta solución no es aplicable en un caso de uso que requiere replicación de datos. Esta solución es aplicable si necesita que los usuarios de Salesforce vean información de un sistema externo que no debe o no puede replicarse en Salesforce, y el sistema externo no puede admitir protocolos estándar como Odata o GraphQL. Consulte Caso de [uso: Integración saliente utilizando herramientas](#caso-de-uso-integración-saliente-utilizando-herramientas-híbridas) híbridas para un caso de uso de ejemplo para un adaptador personalizado Apex.

**Datos 360** Cuando se actualiza un contacto en sistemas externos como ERP, las actualizaciones de contacto se pueden sincronizar con Data 360 utilizando conectores listos para su uso o utilizando API y herramientas de procódigo como MuleSoft. También se puede hacer referencia al contacto en Data 360 utilizando un mecanismo de copia cero (disponible con algunas plataformas). Una vez que los datos están disponibles en Data 360, se pueden utilizar diferentes mecanismos de integración de uso inmediato para sincronizar los datos con otras organizaciones de Salesforce. Se puede acceder a los datos por referencia utilizando Data Cloud One. Los datos también se pueden replicar utilizando activaciones y otras API utilizando conectores listos para su uso o con la ayuda de herramientas de procódigo como MuleSoft Anypoint Platform.

### Herramientas de procódigo para integraciones entrantes en Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Directrices</th>
            <th>Licencia</th>
            <th>Cronología</th>
            <th>Volumen y escala</th>
            <th></th>
            <th>Entrega y mantenimiento</th>
            <th></th>
            <th></th>
            <th>Privacidad y seguridad</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th>Cuándo utilizar</th>
            <th>Licencia adicional</th>
            <th>Sincronizar (Solicitud/Respuesta) o Asíncronizar (Fuego/Olvido)</th>
            <th>Compatibilidad con múltiples objetos</th>
            <th>LDV/masa</th>
            <th>Pruebas e implementación****</th>
            <th>Depuración</th>
            <th>Comportamiento de reintento/gestión de errores integrado</th>
            <th>Puede utilizar con datos cifrados en periodos de inactividad</th>
            <th>Protocolo de autenticación</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Servicios web REST y SOAP de Apex personalizados</strong></td>
            <td>Cuando necesita más funciones que las proporcionadas por los extremos de API nativos como procesamiento de objetos cruzados u otra lógica compleja.</td>
            <td>No se requiere</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>Con herramientas de procódigo</td>
            <td>No</td>
            <td class="guide-table-ok">Sí***</td>
            <td>Múltiples</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td>Cuando necesita una única solución unificada de nivel de compañía para crear, orquestar y gestionar sus integraciones; cuando necesita sustituir una arquitectura de punto a punto heredada; o cuando necesita asistencia de gestión de API.</td>
            <td>Requerido</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>Con herramientas de procódigo</td>
            <td>No</td>
            <td class="guide-table-ok">Sí***</td>
            <td>Múltiples</td>
        </tr>
        <tr>
            <td><strong>API nativas de Salesforce</strong></td>
            <td>Cuando necesita más control o tiene un conjunto de habilidades de procódigo para crear integraciones a través de API de REST, API de SOAP, API masiva o API de GraphQL o gRPC.</td>
            <td>No requerido*</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sí*****</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>Con herramientas de procódigo</td>
            <td class="guide-table-ok">Sí**</td>
            <td class="guide-table-ok">Sí***</td>
            <td>Múltiples</td>
        </tr>
    </tbody>
</table>

\*Se aplican [límites y asignaciones](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_api.htm) de solicitudes de API.

\*\*Las API masivas tienen aspectos de comportamiento de reintento y un número de API ofrecen protección _contra reversiones_ a través de la configuración allOrNone (por ejemplo, consulte [Parámetros allOrNone en solicitudes compuestas y de recopilaciones](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_composite_allornone.htm))

\*\*\*Activar Shield Platform Encryption cambia ciertos comportamientos, consulte [Consideraciones generales Shield Platform Encryption](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5) para obtener más detalles.

\*\*\*\*Pruebas e implementación hace referencia a la capacidad de construir en un entorno inferior e implementar a través de la [API de metadatos](https://developer.salesforce.com/docs/metadata-coverage/), paquetes o conjuntos de cambios en producción.

\*\*\*\*\*Las API compuestas tienen compatibilidad con múltiples objetos.

### Caso de uso: Integración entrante utilizando herramientas de código profesional

> Un contacto se actualiza en el sistema ERP de la organización. Esta información de contacto debe actualizarse en Salesforce.

**Servicios web Apex REST y SOAP** personalizados Puede crear un servicio web utilizando código Apex que podría realizar operaciones CRUD (crear, leer, actualizar, eliminar) en el objeto Contacto. Este servicio se invocará a través de SOAP o REST desde el sistema externo (el sistema ERP).

**MuleSoft Anypoint** La intención de MuleSoft Anypoint es proporcionar gestión de API de nivel de compañía. MuleSoft Anypoint ofrece un [gran conjunto de conectores preintegrados](https://www.mulesoft.com/platform/cloud-connectors) que puede utilizar para integrar con muchos sistemas ERP incluyendo SAP, Oracle EBS, Oracle ERP y NetSuite. Puede crear un flujo para escuchar eventos en estos sistemas ERP (en este caso, cuando se crea un nuevo contacto). Cuando se inicia el flujo, utiliza el conector de Salesforce para crear un nuevo registro Contacto (o actualizar uno si el contacto ya existe). Además, es posible integrar con otros sistemas si la transacción de replicación implica distribuir el contacto en otros sistemas. Si es necesario, puede utilizar el lenguaje de asignación y transformación (DataWeave) para realizar cálculos y lógica compleja como flujos de información entre múltiples sistemas dispares. La autenticación en estos sistemas se puede realizar a través de muchos mecanismos de autenticación diferentes como Autenticación básica y OAuth, entre otros. No hay restricciones en el volumen de transacciones siempre que el flujo tenga el tamaño adecuado para su utilización máxima (medida en vCores).

**API nativas de Salesforce** Cuando (o inmediatamente después) se completa la transacción de actualización en el sistema ERP, puede realizar una operación de alteración en el objeto Contacto a través de la API de SOAP o realizar un [PARCHE](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/dome_update_fields.htm) en la API de REST de sObjects de Contacto en la organización de Salesforce.

## Integraciones de Salesforce a Salesforce

El producto Salesforce to Salesforce alcanzó su fin de vida útil. Salesforce to Salesforce facilitó a los socios que trabajan juntos la tarea de vender y dar asistencia a clientes conjuntos, pero Salesforce invertirá en aportar más innovación a otras herramientas. En adelante, se recomiendan los siguientes enfoques para compartir datos entre organizaciones de Salesforce.

### Herramientas para la integración de datos entre organizaciones de Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Directrices</th>
            <th>Costo</th>
            <th>Cronología</th>
            <th>Volumen y escala</th>
            <th></th>
            <th></th>
            <th>Entrega y mantenimiento</th>
            <th></th>
            <th>Privacidad y seguridad</th>
            <th></th>
            <th>Herramientas para implementar</th>
        </tr>
        <tr>
            <th></th>
            <th><strong>Cuándo utilizar</strong></th>
            <th><strong>Licencia adicional</strong></th>
            <th><strong>Sincronizar (Solicitud/Respuesta) o Asíncronizar (Fuego/Olvido)</strong></th>
            <th><strong>Compatibilidad con múltiples objetos</strong></th>
            <th><strong>LDV/masa</strong></th>
            <th><strong>Pruebas e implementación*</strong></th>
            <th><strong>Depuración</strong></th>
            <th><strong>Comportamiento de reintento/gestión de errores integrado</strong></th>
            <th><strong>Puede utilizar con datos cifrados en periodos de inactividad</strong></th>
            <th><strong>Protocolo de autenticación</strong></th>
            <th><strong>Código bajo → Código profesional</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td>Cuando desea ampliar sus datos con sincronización bidireccional entre organizaciones de Salesforce y también activar el acceso a los datos desde aplicaciones móviles y otras que se ejecutan en Heroku</td>
            <td>Requerido</td>
            <td>Async</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>No</td>
            <td>Con herramientas de procódigo</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí, a través de Shield Connect</td>
            <td>OAuth</td>
            <td>Código bajo</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td>Cuando necesita una única solución unificada de nivel de compañía para crear, orquestar y gestionar sus integraciones; cuando necesita sustituir una arquitectura de punto a punto heredada; o cuando necesita asistencia de gestión de API</td>
            <td>Requerido</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>Con herramientas de procódigo</td>
            <td>No</td>
            <td class="guide-table-ok">Sí**</td>
            <td>Múltiples</td>
            <td>Código Pro</td>
        </tr>
        <tr>
            <td><strong>API nativas de Salesforce</strong></td>
            <td>Cuando Salesforce o Heroku Connect no son una opción o necesita un procesamiento más complejo</td>
            <td>No se requiere</td>
            <td>Ambos</td>
            <td>No</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>Con herramientas de procódigo</td>
            <td>No</td>
            <td class="guide-table-ok">Sí**</td>
            <td>Múltiples</td>
            <td>Código Pro</td>
        </tr>
        <tr>
            <td><strong>Captura de datos</strong></td>
            <td>Cuando necesita publicar cambios a nivel de registro realizados en Salesforce en un sistema externo y no necesita una carga personalizada.</td>
            <td>Requerido</td>
            <td>Async</td>
            <td>No</td>
            <td>No</td>
            <td class="guide-table-ok">Sí</td>
            <td>Con herramientas de procódigo</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>OAuth</td>
            <td></td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect con adaptador entre organizaciones</strong></td>
            <td>Cuando desea que los usuarios en una organización vean o modifiquen registros en una organización diferente sin replicación de datos</td>
            <td>Requerido</td>
            <td>Async</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>Con herramientas de procódigo</td>
            <td>N/A</td>
            <td>N/A</td>
            <td>Múltiples</td>
            <td>Código bajo</td>
        </tr>
        <tr>
            <td><strong>Data 360</strong></td>
            <td>Cuando desea que los usuarios de una organización vean o modifiquen registros en una organización diferente con datos replicados en Data 360.</td>
            <td>Requerido</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>Con herramientas de procódigo</td>
            <td class="guide-table-ok">Sí</td>
            <td class="guide-table-ok">Sí</td>
            <td>Múltiples</td>
            <td>Híbrido</td>
        </tr>
    </tbody>
</table>

\*Pruebas e implementación hace referencia a la capacidad de construir en un entorno inferior e implementar a través de la [API de metadatos](https://developer.salesforce.com/docs/metadata-coverage/), paquetes o conjuntos de cambios en producción

\*\*La activación Shield Platform Encryption cambia ciertos comportamientos, consulte [Consideraciones generales Shield Platform Encryption](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5) para obtener más detalles.

Los eventos de _plataforma no son óptimos para integrar datos desde una organización de Salesforce a otra, porque no pueden “escuchar” entre organizaciones para el mismo evento. Apex personalizado tampoco es un enfoque recomendado para este tipo de integración._

### Caso de uso: Conexión de múltiples organizaciones de Salesforce

> Una gran empresa opera entre múltiples unidades de negocio (BU). Cada BU tiene su propia organización de Salesforce. Un único cliente trata con múltiples unidades de negocio de la compañía y, por lo tanto, tiene datos de cuentas y oportunidades en múltiples organizaciones. La compañía necesita acceder a una vista agregada de todos los datos de Cuenta y Oportunidad entre todas las unidades de negocio en una sola organización.

_Nota: Todas las soluciones a continuación están diseñadas para la menor cantidad de replicación de datos, de acuerdo con la [Conclusión #1](#comida-para-llevar)._

Los datos de cuentas y oportunidades de **Data 360** de diferentes organizaciones de Salesforce se pueden ingresar en Data 360 utilizando conectores de Salesforce listos para su uso. También se pueden agregar y armonizar (si es necesario). Una vez agregados los datos en Data 360, se puede acceder a ellos en otras organizaciones de Salesforce utilizando Data Cloud One sin replicación de datos.

**Heroku Connect** Para la organización individual de cada unidad de negocio, puede utilizar Heroku Connect para sincronizar cambios desde Salesforce en una única base de datos Postgres de Heroku. En este escenario, la sincronización bidireccional no está activada, solo la sincronización desde Salesforce a Postgres. A continuación, en Heroku Connect, puede activar el proveedor de Odata y seleccionar las tablas que desea exponer como objetos externos en la organización de Salesforce donde desea una vista agregada. Desde Salesforce, define una fuente de datos externa que apunta al proveedor de Odata en Heroku.

**MuleSoft Anypoint** MuleSoft Anypoint proporciona gestión de API de nivel de compañía. Se puede configurar una API de MuleSoft Anypoint de modo que lea información de múltiples organizaciones de Salesforce relacionadas utilizando el conector de Salesforce con múltiples conexiones con las organizaciones. El flujo de MuleSoft puede consultar las diferentes organizaciones de Salesforce y devolver una estructura específica mejorada o enriquecida con otra información externa si es necesario. Cuando se invoca la API, realizará todas las llamadas de organización de Salesforce apropiadas (en este ejemplo consultando información de Cuenta y Oportunidad) de modo que los datos puedan procesarse por el consumidor (probablemente una interfaz de usuario). La autenticación en estos sistemas se puede realizar a través de una variedad de mecanismos de autenticación incluyendo autenticación básica y OAuth. No hay restricciones en el volumen de transacciones, siempre que el flujo se haya dimensionado correctamente para su utilización máxima (medida en vCores o Núcleos).

Las operaciones de consulta de las **API nativas de Salesforce** se pueden enviar a cada una de las organizaciones de interés, especialmente a través de la API masiva de Salesforce 2.0, que es adecuada para extraer miles de registros de forma eficiente. Puede recuperar los resultados de la consulta de cada organización individualmente y agregarlos con una aplicación personalizada o middleware por requisitos de cliente.

**Salesforce Connect con adaptador entre organizaciones** El adaptador entre organizaciones Salesforce Connect no encaja bien en este escenario, ya que las cuentas u oportunidades de organizaciones remotas aparecerán todas en la organización central como objetos _diferentes_. Por ejemplo, no hay forma de agregar un total general para los Importes de todas las Oportunidades entre todas las organizaciones.

**Escenario de actualizaciones selectivas entre organizaciones:** Un vendedor que utilice la organización A de Salesforce debe ver y actualizar los datos del caso desde la organización B de Salesforce y agregar comentarios de casos al caso principal en la organización B de Salesforce mientras trabaja en la organización A. Los datos no deben replicarse en la organización A.

**Heroku Connect** Puede utilizar el mismo enfoque descrito en el _Escenario de agregación_ de datos anterior. Sin embargo, debe activar CRUD en el objeto externo a través del conector Odata y redactar los cambios de vuelta en Postgres de Heroku.

**MuleSoft Anypoint** MuleSoft Anypoint proporciona gestión de API de nivel de compañía. Puede utilizar el mismo enfoque descrito en el _Escenario de agregación_ de datos anterior.

Las **API nativas de Salesforce** utilizan credenciales nombradas e invocan las API nativas de Salesforce para leer y actualizar datos en la organización de Salesforce relacionada. Un componente debe estar diseñado para mostrar los datos.

**Salesforce Connect con adaptador entre organizaciones** La capacidad de ver datos en un objeto externo (así como modificar los datos si tiene CRUD activado en el objeto externo) se admite a través del [adaptador entre organizaciones](https://help.salesforce.com/articleView?id=sf.xorg_adapter_about.htm&type=5) de Salesforce. Las relaciones también son compatibles entre objetos externos de modo que puede vincular al caso principal en el objeto externo. Sin embargo, la creación de relaciones es un proceso manual hoy en día en el que convierte un tipo de datos existente en un tipo de datos de relación. Además, las optimizaciones realizadas en Service Cloud para trabajar con Casos de forma más efectiva no se transmiten en cascada a la organización remota. Salesforce recomienda encarecidamente probar el adaptador entre organizaciones y evaluar las ventajas de trabajar con objetos externos frente a objetos estándar para su caso de uso.

**Sincronización de datos entre organizaciones**: Cuando se actualiza una cuenta para un cliente en una de las organizaciones de Salesforce de la unidad de negocio de la organización, los otros objetos Cuenta de la organización de Salesforce deben actualizarse para mantener la información de cuenta coherente.

**Data 360** Data 360 se puede utilizar para la replicación de datos desde una organización a otra organización de Salesforce. Los datos de cuentas de una organización de Salesforce se pueden ingresar en Data 360 utilizando conectores de Salesforce listos para su uso. Podemos utilizar mecanismos de activación de datos como activación por lotes, acciones de datos casi en tiempo real o activaciones basadas en API también para mover los datos de Data 360 a la organización de Salesforce.

**Heroku Connect** Puede utilizar el mismo enfoque descrito en el _Escenario de agregación_ de datos anterior. Sin embargo, debe activar la sincronización bidireccional y ya no necesita activar Salesforce Connect ya que la sincronización bidireccional mantendrá todas las organizaciones al día cuando se realicen cambios en la tabla Postgres.

**MuleSoft Anypoint** MuleSoft Anypoint proporciona gestión de API de nivel de compañía. Puede [configurar una aplicación](https://docs.mulesoft.com/design-center/about-designing-a-mule-application) Mule con Flow Designer en MuleSoft Anypoint para escuchar eventos de objetos estándar y personalizados para iniciar un flujo iniciado automáticamente en Salesforce. Cuando se desencadena la aplicación Mule, puede invocar el conector Anypoint para Salesforce para comunicarse con cualquier número de organizaciones de Salesforce. En este caso de uso, cuando se actualiza un registro Cuenta en una organización de Salesforce, la aplicación Mule puede actualizar registros Cuenta en las organizaciones de Salesforce relacionadas. Cada organización de Salesforce relacionada tendría un paso de actualización exclusivo integrado en el flujo de aplicación general en MuleSoft. La autenticación en estos sistemas se puede realizar a través de varios mecanismos de autenticación, incluyendo autenticación básica y OAuth. No hay restricciones en el volumen de transacciones siempre que el flujo se haya dimensionado correctamente para su utilización máxima (medida en vCores o Núcleos).

**API nativas de Salesforce** La [API de replicación](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_guidelines_datareplication.htm) (operaciones getUpdated, getDeleted) podría utilizarse para sincronizar datos entre organizaciones, pero no se recomienda este enfoque.

**Salesforce Connect con adaptador entre organizaciones** Puede utilizar flujos desencadenados por registros y objetos externos para mantener algunos datos sincronizados entre organizaciones de Salesforce. Por ejemplo, la actualización de un registro de cuenta en la Organización A desencadena un flujo que luego actualiza el registro coincidente en el objeto externo Cuenta, que escribe esas actualizaciones en el registro de cuenta en la Organización B. Esto requiere el uso adecuado de la semántica de flujos para evitar [transacciones DML mezcladas](https://help.salesforce.com/articleView?id=000328873&type=1&mode=1). Además, tenga en cuenta que las reglas de validación y los flujos en la organización B se desencadenarán del mismo modo que cuando se realicen cambios por nuestras API de REST/SOAP.

## Observaciones finales

Tenga en cuenta esta guía y remítase a ella cuando planifique una nueva integración de datos que implique Salesforce. Siempre es una buena idea comprender el alcance completo de las opciones disponibles para usted y cómo pueden ajustarse a su caso de uso específico.

### Dinos lo que piensas

Ayúdenos a asegurarse de que estamos publicando lo más relevante para usted. [Realice nuestra encuesta](https://sfdc.co/J0cWb) para proporcionar comentarios sobre este contenido e indicarnos qué le gustaría ver a continuación.

<!-- document id=eebaf925f5cb2038f96a0dded4f1b7c10e8ca2c5d80d29d105320b5ee7b1f513 url=/architect/next/es-mx/decision-guides/guides/data-360-interoperability.md -->

## Descripción general

Las compañías a menudo almacenan datos en Salesforce y otros lagos de datos externos como Snowflake, Google BigQuery, Databricks, Redshift o almacenamiento en la nube como Amazon S3. Este aislamiento de datos en diferentes sistemas de origen supone un reto para las compañías que desean aprovechar toda la potencia de sus datos.

Los arquitectos que trabajan para reunir datos entre múltiples lagos de datos se enfrentan a decisiones arquitectónicas clave sobre cómo integrar mejor esos datos. Data 360 ofrece múltiples opciones para la integración de datos, cada una de las cuales ofrece diferentes pros y contras.

Esta guía proporciona un marco de trabajo para evaluar qué patrón se ajusta mejor a sus requisitos de latencia, costo, capacidad de ampliación, gobernanza y complejidad al integrar datos, ayudándole a elegir cuándo utilizar el ingreso de datos, la federación de datos Cero copia o un enfoque híbrido. La guía también le ayudará a seleccionar entre diferentes métodos de ingreso de datos y federación de datos, cada uno de los cuales satisface una necesidad diferente.

La integración de lagos de datos externos con Data 360 requiere una cuidadosa consideración de las compensaciones entre la actualización de datos, la gobernanza y la eficiencia de las oportunidades en curso. Por ejemplo, el uso de consultas en vivo de federación de datos Cero copia maximiza la actualización de los datos pero puede reducir la eficiencia de las oportunidades en curso a medida que mueve más datos por la red. Por lo tanto, para la mayoría de las implementaciones del mundo real, una combinación de ingreso y federación en un ecosistema de lago de múltiples nubes es la ruta óptima. Este enfoque híbrido garantiza una arquitectura ampliable, gobernada e interoperable que admite sin problemas cargas de trabajo operativas de baja latencia como la personalización en tiempo real y la detección de fraudes, así como cargas de trabajo analíticas como los reportes normativos y el análisis de tendencias históricas. Esta guía de decisiones le ayudará a comprender cómo navegar por estas compensaciones y seleccionar la estrategia correcta.

## Comida para llevar

- **Ingreso de datos:** Copia datos en Salesforce Data 360, creando modelos de datos gobernados y canónicos. Ideal cuando necesita:
  - **Cree un Customer 360 integral:** Unifique y transforme orígenes dispares en un único perfil de confianza.
  - **Cumplir el estricto cumplimiento normativo:** Cree una copia auditable y centralizada donde el acceso a los datos y el linaje puedan controlarse estrictamente.
- **Federación de copia cero:** Consulta fuentes externas en tiempo real sin duplicaciones, lo que permite la personalización en tiempo real, los tableros en vivo y la incorporación rápida de fuentes. Dos opciones principales con compensaciones que debe equilibrar:
  - **En vivo y en caché (Consulta acelerada):** Lo mejor para análisis interactivos y tableros en tiempo real en datos que viven en plataformas de datos externas como Snowflake, Google BigQuery, Redshift o Databricks. Evita la duplicación de datos lenta y costosa enviando el procesamiento al sistema de origen.
  - **Federación de archivos:** Ideal para el procesamiento por lotes a gran escala y el entrenamiento de modelos de IA en datos en su lago de datos de nube (S3, ADLS). Evita el ingreso costoso y lento consultando directamente archivos en formatos de tabla abierta, desbloqueando conjuntos de datos masivos para cargas de trabajo de ciencias de datos y ETL.
- **Modelo híbrido:** Combine el ingreso para Perfiles unificados con la federación para una mayor frescura, lo que admite la implicación de OmniCanal, acciones dirigidas por Agentforce y capacitación de IA/ML.

### Consideraciones importantes

- **Arquitectura híbrida:** La mezcla de ingreso de datos y federación de datos a menudo es necesaria.

  - Utilice Ingreso de datos en datos críticos para modelos de datos canónicos y gobernanza principal.
  - Organice todos los demás datos a través de Cero copia para minimizar la carga operativa de la creación y el mantenimiento de las oportunidades en curso de datos de ingreso.

- **La frecuencia de ingreso de datos importa:** Seleccione la frecuencia basándose en el valor de negocio, las necesidades de latencia y la complejidad operativa.

  - Utilice el tiempo real para flujos de trabajo urgentes (personalización, tableros en vivo, acciones Agentforce).
  - Casi en tiempo real para procesos de urgencia moderada (campañas, reportes operativos).
  - Lote para conjuntos de datos históricos o de baja velocidad.

- **Coincidencia del patrón de federación con latencia y desempeño:** Seleccione el que mejor se ajuste a sus patrones de acceso y los requisitos de frescura, desempeño y costo.

  - Utilice Live Query para tableros operativos y personalización en tiempo real donde la baja latencia es crítica.
  - Utilice el almacenamiento en caché (Consulta acelerada) cuando las consultas son frecuentes pero los resultados ligeramente obsoletos son aceptables, lo que equilibra el desempeño y el costo.
  - Utilice Federación de archivos para análisis a gran escala y con alto rendimiento o cargas de trabajo por lotes que son ideales para conjuntos de datos históricos o menos urgentes.

- **Alinear la gobernanza con los requisitos de residencia de datos:**

  - Utilice el ingreso donde la regulación centralizada es crítica.
  - Utilice la federación donde la gobernanza descentralizada es aceptable, mientras aplica una gobernanza estricta en el origen externo. Cero copia respeta políticas a nivel de origen como la seguridad a nivel de filas (RLS) y el enmascaramiento de datos.

- **Dar prioridad al ingreso para flujos de trabajo de alto valor:** Aplique el ingreso de forma selectiva a procesos críticos como la resolución de identidad, la creación de reportes regulatorios y la activación operativa.

- **Costo y complejidad dirigen la decisión:** El ingreso en tiempo real puede ser costoso y complejo. Los arquitectos deben sopesar el costo de incorporar, almacenar y transformar datos con el costo de consultarlos directamente a través de Cero copia.

La selección del patrón de integración correcto (Ingreso de datos, Cero copia o un enfoque híbrido) afecta directamente a la latencia, la gobernanza, la eficiencia operativa y el costo entre plataformas de múltiples nubes. Esta decisión determina cómo se pueden entregar perspectivas en tiempo real, activación dirigida por IA e implicación personalizada de forma fiable y a escala.

## Comparación de productos

Esta tabla proporciona una comparación técnica de patrones de ingreso de datos y copia cero en Salesforce Data 360, centrándose en funciones, compensaciones y beneficios, junto con casos de uso y resultados de negocio. Los arquitectos pueden utilizar esto como una referencia para el diseño de plataformas de datos híbridas de múltiples nubes que equilibran el desempeño, el costo y el cumplimiento.

<table>
  <thead>
    <tr>
      <th align="left" valign="top" width="8%">Tipo de patrón</th>
      <th align="left" valign="top" width="15%">Modo / Herramienta</th>
      <th align="left" valign="top" width="12%">Beneficios</th>
      <th align="left" valign="top" width="32%">Consideraciones</th>
      <th align="left" valign="top" width="33%">Resultados</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td align="left" valign="top"><strong>Ingreso de datos</strong></td>
      <td align="left" valign="top"><strong>Tiempo real:</strong> Ingreso de latencia por debajo del segundo a través de las API de ingreso con compatibilidad de CDC. Canalizaciones de transmisión continua.</td>
      <td align="left" valign="top">- Perspectivas inmediatas<br>- Ideal para casos de uso operativos y de personalización de baja latencia<br>- Admite flujos de trabajo dirigidos por eventos</td>
      <td align="left" valign="top">- Alto costo<br>- Arquitectura compleja<br>- Requiere sistemas de origen de baja latencia<br>- Las fuentes de gran volumen pueden causar una transmisión excesiva que conduce a oportunidades en curso saturadas<br>- E/S intensiva<br>- Considerar campos selectivos y filtrado para reducir los gastos generales</td>
      <td align="left" valign="top"><strong>Agentforce:</strong><br>- Alertas de fraude en tiempo real, personalización minorista, alertas operativas<br><strong>Analytics:</strong><br>- Tableros de subsegundos, monitoreo de KPI<br><strong>Cumplimiento:</strong><br>- Actualizaciones continuas de registros de clientes para flujos de trabajo regulados</td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top"><strong>Transmisión:</strong>Ingreso de microlotes cada 1 a 3 minutos a través de conectores nativos</td>
      <td align="left" valign="top">Costo equilibrado frente a frescura<br>- Arquitectura más sencilla que en tiempo real<br>- Admite actualizaciones incrementales</td>
      <td align="left" valign="top">- Latencia ligera<br>- Puede no ser adecuado para decisiones críticas de subsegundos<br>- El tamaño de lote afecta a la memoria/cómputo<br>- E/S es moderada<br>- Lo mejor para patrones de actualización predecibles y repetidos<br>- Considere la agregación con ventanas para reducir la carga de procesamiento</td>
      <td align="left" valign="top"><strong>Agentforce:</strong><br>- Desencadenadores de campaña oportunos, implicación casi en vivo<br><strong>Analytics:</strong><br>- Motores de recomendaciones, tableros casi en vivo<br><strong>Cumplimiento:</strong><br>- Actualizaciones frecuentes con capacidad de auditoría</td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top"><strong>Lote:</strong> Cargas de gran volumen programadas a través de conectores o API. Admite almacenamiento de objetos y oportunidades en curso de ETL/ELT.</td>
      <td align="left" valign="top">- Costo-eficiente para conjuntos de datos masivos<br>- Fácil de implementar<br>- Fiable para análisis históricos</td>
      <td align="left" valign="top">- Latencia de datos<br>- Inadecuado para operaciones urgentes<br>- E/S intensiva durante los plazos de carga<br>- El rendimiento de red puede convertirse en un cuello de botella para archivos de gran tamaño<br>- Ideal para flujos de trabajo de agregación histórica o creación de reportes regulados</td>
      <td align="left" valign="top"><strong>Agentforce:</strong><br>- Tickets de asistencia de TI (Jira/ServiceNow), flujos de trabajo agregados<br><strong>Analytics:</strong><br>- Análisis histórico, evaluación de tendencias<br><strong>Queja:</strong><br>- Creación de reportes reguladores, agregación de datos de pacientes/reclamaciones</td>
    </tr>
    <tr>
      <td align="left" valign="top"><strong>Zero Copy</strong></td>
      <td align="left" valign="top"><strong>Consulta en vivo:</strong> Consultas directas en sistemas externos; esquema en lectura; sin duplicación de datos</td>
      <td align="left" valign="top">- Máxima frescura<br>- Gastos generales de almacenamiento mínimos; admite perspectivas operativas en tiempo real</td>
      <td align="left" valign="top">-Dependiendo del desempeño de origen<br>- El alto volumen de consultas puede afectar a la latencia<br>- Ideal para consultas con distribución y agregación de predicados para minimizar las E/S<br>- Evitar consultas sin filtrar en conjuntos de datos masivos</td>
      <td align="left" valign="top"><strong>Agentforce:</strong><br>- Flujos de trabajo dinámicos adaptándose a la actividad en vivo<br><strong>Analytics:</strong><br>- Tableros operativos, creación de reportes en vivo<br><strong>Cumplimiento:</strong><br>- Respeta la seguridad a nivel de filas y el enmascaramiento en origen</td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top"><strong>Consulta acelerada (almacenamiento en caché):</strong> Copias locales en caché para consultas federadas. Configurable de 15 min a 7 días. Ejecución de consultas optimizada</td>
      <td align="left" valign="top">- Reduce la latencia<br>- Menor costo que las consultas en vivo repetidas<br>- Mejora el desempeño para patrones de acceso frecuente</td>
      <td align="left" valign="top">- Gestión de caché requerida<br>- El estado depende del intervalo de caché<br>- Ideal para consultas de alta frecuencia<br>- No apto para la decisión de subsegundos</td>
      <td align="left" valign="top"><strong>Agentforce:</strong><br>- Mediciones de implicación preagregadas para una decisión rápida<br><strong>Analytics:</strong><br>- Tableros de BI, segmentación, creación de reportes analíticos<br><strong>Cumplimiento:</strong><br>- Tableros regulados coherentes con registros de auditoría</td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top"><strong>Federación de archivos:</strong> Acceso directo a grandes conjuntos de datos históricos en establecimientos de objetos o lagos (S3, Iceberg, Google BigQuery, Redshift).</td>
      <td align="left" valign="top">- Gestiona conjuntos de datos a gran escala<br>Almacenamiento mínimo en Data 360<br>- Admite cargas de trabajo de IA/ML</td>
      <td align="left" valign="top">-Solo lectura<br>- El desempeño de las consultas depende del rendimiento del sistema externo<br>- Optimizado para trabajos intensivos de rendimiento y por lotes<br>- No apto para tablero en tiempo real</td>
      <td align="left" valign="top"><strong>Agentforce:</strong><br>- (No es típico — pesado por lotes)<br><strong>Analytics:</strong><br>- Entrenamiento de ML/IA, análisis histórico, creación de reportes a escala de petabytes<br><strong>Cumplimiento:</strong><br>Acceso regulado a conjuntos de datos externos sin duplicación</td>
    </tr>
  </tbody>
</table>

## Patrones de integración de Data 360

### Ingreso de datos

Con el ingreso de datos, los datos se copian físicamente en Data 360 y se rigen completamente, a diferencia de Cero copia donde los datos permanecen en el origen. Computar las transformaciones se produce en Data 360, lo que permite la gestión y la auditoría centralizadas.

#### Casos de uso de ingreso de datos

Utilice el ingreso de datos para almacenar conjuntos de datos gobernados canónicos en Salesforce Data 360 para el cumplimiento y el control operativo. Utilice el ingreso cuando se requiera control completo, auditoría y trazabilidad. Ideal para flujos de trabajo regulados o de alto valor donde la computación centralizada y la gobernanza son fundamentales.

El ingreso es el mejor para crear una base de confianza para la resolución de identidad, la creación de reportes regulatorios, flujos de trabajo dirigidos por IA de misión crítica y la implicación de clientes.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Data Ingestion and Zero Copy - Data 360  Ingestion.png" alt="Descripción general de ingreso de datos" />

#### Métodos de ingreso de datos

Los métodos de ingreso de datos varían dependiendo del conector que utilice para ingresar sus datos. Algunos conectores ofrecen una variedad de métodos de ingreso, mientras que otros solo funcionan en modo por lotes o transmisión. Consulte [Datos 360: Integraciones y conectores](https://help.salesforce.com/s/articleView?id=data.c360_a_sources_targets.htm&type=5) para una lista completa de conectores de Data 360 y sus métodos disponibles.

- **En tiempo real**
  - Ingreso de subsegundos utilizando oportunidades en curso de transmisión o Captura de datos de cambios (CDC).
  - Ideal para flujos de trabajo urgentes (detección de fraude, personalización, tableros operativos).
  - Distribuya transformaciones y agregaciones en Data 360 para reducir las E/S descendentes y optimizar el uso de computación. Utilice CDC incrementales para minimizar la reorganización de datos.
- **Transmisión**
  - Ingesta cada 1-3 minutos en pequeños incrementos.
  - Equilibra la frescura y el costo, adecuados para la orquestación de campañas, la implicación casi en vivo y los reportes operativos.
  - Utilice microlotes para controlar picos de E/S. Agregue datos en origen si es posible para reducir los volúmenes de transferencia y optimizar el almacenamiento.
- **Lote (Cargas programadas)**
  - Ingreso periódico de grandes conjuntos de datos (por hora, diariamente, semanalmente).
  - Rentable y fiable para conjuntos de datos históricos, creación de reportes regulatorios y casos de uso de cumplimiento.
  - Asegúrese de calcular la localidad en la misma región que el almacenamiento de origen para la optimización de desempeño y costos.

#### Libro de jugadas de arquitecto

- **Casos de uso para ingreso de datos**
  - **Generar perfiles unificados Customer 360:** Creación de una fuente de verdad única para la identidad y los atributos del cliente.
  - **Mantener conjuntos de datos de cumplimiento normativo:** Aplicación de la gobernanza, el linaje y la capacidad de auditoría para datos confidenciales.
  - **Centralice la orquestación de campañas:** Garantizar que marketing, ventas y servicio funcionan desde conjuntos de datos coherentes y de confianza.
- **Prácticas de diseño**
  - Favorezca el ingreso por lotes para necesidades históricas o tolerantes a baja latencia, como creación de reportes de archivo o instantáneas periódicas.
  - Utilice las API de transmisión o CDC para mantener la actualización para flujos de trabajo operativos y de personalización, garantizando actualizaciones casi en tiempo real.
  - Controle el almacenamiento y calcule el crecimiento aplicando cargas incrementales, en vez de volver a cargar conjuntos de datos completos, para optimizar el costo y la eficiencia.
  - Alinee las oportunidades en curso de ingreso con la localidad de cálculo y el procesamiento incremental para reducir la E/S de red. Aplique transformaciones dentro de Data 360 para evitar mover datos sin procesar innecesariamente.
- **Consideraciones de costos**
  - **Ingreso en tiempo real:** Costos de computación y oportunidades en curso más altos; justificados para flujos de trabajo de alto valor y urgentes como personalización, tableros operativos o acciones dirigidas por Agentforce.
  - **Ingreso de transmisión:** Modere los costos de computación y almacenamiento; adecuado para actualizaciones frecuentes que pueden tolerar ligeros retrasos, como orquestación de campañas o creación de reportes operativos.
  - **Ingestión por lotes:** Costos de computación más bajos, almacenamiento predecible; lo mejor para conjuntos de datos históricos o actualizaciones de baja frecuencia. El ingreso de datos por lotes desde organizaciones de Salesforce utilizando ciertos conectores es gratuito.
  - **Modo de actualización:** La selección del modo Actualización incremental reduce el ingreso total y calcula los costos. Recomendamos utilizar la actualización incremental siempre que sea posible para optimizar la eficiencia entre todos los tipos de ingreso.
  - El costo también se ve afectado por el volumen de E/S desde el origen a Data 360. La optimización de tamaños de lote, particiones y alineación regional reduce los costos de transferencia y mejora el desempeño.
- **Escenarios industriales**
  - **Finanzas:** Ingrese los conjuntos de datos requeridos para conocer a su cliente (KYC), Antilavado de dinero (AML) y detección de fraude, donde la capacidad de auditoría y el cumplimiento no son negociables.
  - **Cuidados sanitarios:** Utilice el ingreso para la resolución de identidad de pacientes y registros compatibles con HIPAA, permitiendo vistas seguras y unificadas.
  - **Retail:** Consolidar datos de punto de venta (POS), comercio electrónico y programa de fidelidad en perfiles unificados para segmentación y personalización
  - **Telecom:** Apoye la prevención de abandonos y los análisis de uso con datos de suscriptor gobernados canónicos.

#### Criterios de decisión de método de ingreso de datos

<table>
<thead>
<tr>
<th>Función</th>
<th>Ingreso en tiempo real</th>
<th>Ingreso de transmisión</th>
<th>Ingestión por lotes</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Latencia y frescura</strong></td>
<td>Ingreso de latencia por debajo del segundo a través de las API de ingreso con compatibilidad con Captura de datos de cambios (CDC). Proporciona oportunidades en curso de transmisión continua. Ideal para casos de uso operativos de baja latencia.</td>
<td>Ingreso de microlotes cada 1 a 3 minutos a través de conectores nativos. Admite actualizaciones incrementales. Se espera una ligera latencia.</td>
<td>Se espera latencia de datos. Cargas de gran volumen programadas. Ingestión periódica (por hora, diariamente, semanalmente). Inadecuado para operaciones urgentes.</td>
</tr>
<tr>
<td><strong>Casos de uso principales</strong></td>
<td>Ideal para casos de uso operativos y de personalización de baja latencia. Se utiliza para flujos de trabajo urgentes. Admite flujos de trabajo dirigidos por eventos. Se utiliza para alertas de fraude en tiempo real y alertas operativas.</td>
<td>Adecuado para procesos de urgencia moderada. Se utiliza para orquestación de campañas, implicación casi en vivo y creación de reportes operativos. Se utiliza para desencadenadores de campaña oportunos.</td>
<td>Rentable para conjuntos de datos masivos. Fiable para análisis históricos. Se utiliza para flujos de trabajo de agregación histórica o creación de reportes regulados. Ideal para conjuntos de datos históricos o de baja velocidad.</td>
</tr>
<tr>
<td><strong>Complejidad arquitectónica y E/S</strong></td>
<td>Arquitectura compleja y de alto costo. Requiere sistemas de origen de baja latencia. E/S intensiva. Los orígenes de gran volumen pueden causar oportunidades en curso saturadas.</td>
<td>Arquitectura más sencilla que en tiempo real. E/S es moderada. Lo mejor para patrones de actualización repetidos y predecibles. El tamaño de lote afecta a la memoria/cómputo.</td>
<td>Fácil de implementar. intensivo de E/S durante los plazos de carga. El rendimiento de red puede convertirse en un cuello de botella para lotes grandes.</td>
</tr>
<tr>
<td><strong>Consideraciones de costos</strong></td>
<td>Costos de computación y oportunidades en curso más altos. Solo se justifica para flujos de trabajo de alto valor y urgentes.</td>
<td>Modere los costos de computación y almacenamiento. Proporciona un enfoque de costo frente a frescura equilibrado. Adecuado para actualizaciones frecuentes que pueden tolerar ligeros retrasos.</td>
<td>Reduzca los costos de computación y el almacenamiento predecible. Recomendado para conjuntos de datos históricos o actualizaciones de baja frecuencia. El ingreso a través de oportunidades en curso internas de Salesforce es gratuito.</td>
</tr>
<tr>
<td><strong>Prácticas de diseño</strong></td>
<td>Utilice CDC incrementales para minimizar la reorganización de datos. Filtre y utilice campos selectivos para reducir los gastos generales.</td>
<td>Utilice microlotes para controlar picos de E/S. Considere la agregación con ventanas para reducir la carga de procesamiento.</td>
<td>Favorezca esto para reportes de archivo o instantáneas periódicas. Asegúrese de calcular la localidad en la misma región que el almacenamiento de origen para la optimización de costos.</td>
</tr>
</tbody>
</table>

### Federación de datos de copia cero

#### Cero casos de uso de copia

Utilice Cero copia para la consulta en tiempo real de sistemas externos sin duplicación de datos, permitiendo agilidad, frescura y acceso ampliable a conjuntos de datos grandes o transitorios. Es mejor para tableros en vivo, análisis exploratorios, entrenamiento de modelo de IA/ML e implicación de clientes en tiempo real directamente a través de Salesforce Data 360.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Data Ingestion and Zero Copy - Data 360 Zero Copy.png" alt="Descripción general de federación de datos de copia cero" />

#### Métodos de copia cero

Al utilizar Cero copia, los arquitectos deben decidir además entre tres métodos de federación de datos disponibles, cada uno de los cuales ofrece sus propias ventajas entre frescura, desempeño y costo.

- **Consulta en vivo**
  - Ejecuta consultas directamente en sistemas externos (Snowflake, Google BigQuery, Redshift, Databricks, etc.) sin duplicación de datos.
  - Óptimo cuando los predicados y las agregaciones se pueden empujar hacia abajo, minimizando el movimiento de datos en la red y reduciendo la E/S en el cálculo de Salesforce Data 360.
  - Lo mejor para perspectivas en tiempo real y tableros operativos de baja latencia. Dependiendo del desempeño del sistema externo.
- **Almacenamiento en caché (Consulta acelerada)**
  - Almacena temporalmente copias en caché de datos federados en Salesforce Data 360.
  - Reduce los costos y la latencia de consultas repetidas para conjuntos de datos a los que se accede con frecuencia, con duración configurable (minutos a días).
  - Los datos no se copian de forma permanente ni se rigen completamente; la actualización se gestiona a través de actualizaciones programadas desde el origen.
- **Federación de archivos**
  - Proporciona acceso directo de solo lectura a conjuntos de datos a gran escala en establecimientos de objetos (por ejemplo, S3, GCS con Iceberg).
  - Ideal para cargas de trabajo de IA/ML, análisis históricos y creación de reportes a escala de petabytes sin mover datos.
  - El desempeño de las consultas depende en gran medida del formato del objeto, la partición y la E/S de red. Las exploraciones de gran tamaño pueden generar E/S sustanciales si no están optimizadas.

#### Libro de jugadas de arquitecto

- **Casos de uso**
  - **Personalización en tiempo real y flujos de trabajo adaptativos:** Entregue ofertas dinámicas, recomendaciones y las mejores acciones siguientes a medida que cambia el comportamiento de los clientes.
  - **Tableros en vivo y análisis operativos:** Potencie tableros clave de negocio y KPI directamente desde almacenes externos.
  - **Entrenamiento de modelo de IA/ML con grandes conjuntos de datos externos:** Aproveche datos a escala de petabytes desde lagos de datos y almacenes utilizando Federación de archivos sin moverlos.
- **Escenarios industriales**
  - **Retail/Media:** Active recomendaciones personalizadas e implicación de clientes en tiempo real federando datos de interacciones de contenido o transmisiones de clics.
  - **Finanzas:** Ejecute la detección de fraudes y el puntuaje de riesgos casi en tiempo real consultando almacenes externos sin duplicar datos confidenciales.
  - **Tech/Enterprise:** Admita la creación de reportes entre nubes, tableros de servicio de TI y análisis operativos donde los conjuntos de datos residen en múltiples sistemas.
- **Prácticas de diseño**
  - **Consulta en vivo**
    - Utilizar para consultas de alta QPS y baja latencia cuando la actualización es crítica.
    - Envíe predicados y agregaciones al sistema externo para reducir la reorganización de datos en la red.
    - Evite consultas que exploran volúmenes de datos masivos innecesariamente; considere filtros y poda de particiones.
  - **Federación de archivos**
    - Acceda a conjuntos de datos a escala de petabytes en establecimientos de objetos sin ingreso.
    - Mantenga el almacenamiento de objetos en la misma región de nube que Salesforce computa para minimizar la latencia y los costos de salida.
    - Utilice formatos particionados y columnares (Parquet/ORC) y filtros de distribución para reducir la transferencia de E/S y red.
    - Aproveche la distribución de consultas y predicados para filtrar y agregar datos en el origen, reduciendo el movimiento de datos.
    - Evite el acceso a datos entre regiones a menos que sea necesario, ya que aumenta la E/S, la latencia y los costos.
  - **Almacenamiento en caché (Consulta acelerada)**
    - Almacenar en caché conjuntos de datos a los que se accede frecuentemente para equilibrar el costo y el desempeño.
    - Configure intervalos de actualización para equilibrar la actualización frente al costo de consulta.
  - **Cumplimiento:** Aplique la regulación en el origen aprovechando la seguridad a nivel de filas (RLS) y enmascarando políticas directamente en sistemas federados. A continuación se muestran mejores prácticas para RLS uniforme y enmascaramiento entre plataformas.
    - **Utilice un Id. de compañía centralizado:** Asigne usuarios y entidades en Salesforce Data 360 a un identificador de compañía único y centralizado que se corresponda con identidades en sistemas externos.
    - **Alinear políticas de seguridad:** Garantice que las políticas de enmascaramiento y seguridad a nivel de filas en sistemas federados se aplican basándose en la identidad asignada. Esto mantiene el cumplimiento al consultar datos externos.
    - **Estandarizar esquemas de identidad:** Mantenga atributos de identidad coherentes (email, Id. de usuario, Id. de cliente, etc.) entre todos los orígenes de datos para evitar desajustes e infracciones de acceso.
- **Consideraciones de costos**
  - **Consulta en vivo:** Modelo de pago por consulta: los costos se acumulan en computación externa de Lakehouse y pueden aumentar con un alto QPS. Lo mejor para casos de uso críticos de frescura donde el valor es superior a la variabilidad de costos.
  - **Consulta acelerada (almacenamiento en caché):** Reduce el costo de la consulta en comparación con Consulta en vivo reduciendo las coincidencias en el sistema de origen, pero agrega costos de ingreso de datos por lotes para rellenar y actualizar la caché. Ideal para conjuntos de datos a los que se accede con frecuencia.
  - **Federación de archivos:** Opción de almacenamiento más barata como datos en Almacén de objetos, pero los costos de consulta dependen del tamaño del archivo, la partición y la poda. Ideal para datos históricos o masivos a escala de petabytes.

#### Criterios de decisión de método de copia cero

<table>
<thead>
<tr>
<th>Punto de decisión</th>
<th>Consulta en vivo</th>
<th>Almacenamiento en caché (Consulta acelerada)</th>
<th>Federación de archivos</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>Ubicación de origen</strong> de datos</td>
<td>Lagos de datos externos (Snowflake, Google BigQuery, Redshift, Databricks).</td>
<td>Lagos de datos externos (Snowflake, Google BigQuery, Redshift, Databricks)</td>
<td>Almacenamientos de objetos o lagos de datos en la nube (S3, ADLS, GCS), a menudo utilizando formatos de tabla abiertos como Iceberg.</td>
</tr>
<tr>
<td><strong>Propósito/Caso de uso</strong></td>
<td>Ideal para análisis interactivos y tableros en tiempo real. Lo mejor para la personalización en tiempo real y flujos de trabajo dinámicos.</td>
<td>Lo mejor para cuando las consultas son frecuentes pero los resultados ligeramente obsoletos son aceptables. Adecuado para tableros de BI y segmentación.</td>
<td>Ideal para el procesamiento por lotes a gran escala y el entrenamiento de modelos de IA/ML. Ideal para análisis históricos y creación de reportes a escala de petabytes.</td>
</tr>
<tr>
<td><strong>Frescura/Latencia</strong></td>
<td>Máxima actualización; las consultas se ejecutan directamente en tiempo real. Admite decisiones por debajo del segundo.</td>
<td>Los resultados ligeramente obsoletos son aceptables. La actualización depende del intervalo de caché, configurable de 15 minutos a 7 días.</td>
<td>Optimizado para trabajos intensivos de rendimiento y por lotes. No es adecuado para tableros en tiempo real.</td>
</tr>
<tr>
<td><strong>Patrón de acceso</strong></td>
<td>Ideal para consultas poco frecuentes o ad hoc. Utilizar para consultas de alta QPS (consulta por segundo) y baja latencia donde la actualización es crítica.</td>
<td>Ideal para escenarios de lectura de alta frecuencia. Mejora el desempeño para patrones de acceso frecuentes.</td>
<td>Acceso de solo lectura. Adecuado para conjuntos de datos a escala de petabytes sin ingreso.</td>
</tr>
<tr>
<td><strong>Controladores de desempeño</strong></td>
<td>Muy dependiente del desempeño del sistema de origen externo. Optimizado cuando los predicados y las agregaciones pueden enviarse hacia abajo al origen.</td>
<td>Reduce la latencia en comparación con consultas en vivo repetidas. El desempeño depende de la gestión y el intervalo de caché.</td>
<td>El desempeño depende en gran medida del formato del objeto, la partición y el rendimiento del sistema externo. Utilice formatos particionados y de columnas (Parquet/ORC).</td>
</tr>
<tr>
<td><strong>Consecuencias de costos</strong></td>
<td>Modelo de pago por consulta. Los costos se acumulan en computación de Lakehouse externa. Rentable para consultas poco frecuentes, pero los gastos pueden aumentar con un alto volumen de consultas por segundo (QPS).</td>
<td>Costo inferior al de las consultas en vivo repetidas. Reduce la necesidad de consultar repetidamente el origen externo. Agrega almacenamiento en caché y gastos generales de actualización.</td>
<td>Opción de almacenamiento más barata. Los costos de consulta dependen del tamaño del archivo y la partición.</td>
</tr>
<tr>
<td><strong>Consideración clave</strong></td>
<td>Evite consultas sin filtrar que exploran volúmenes de datos masivos innecesariamente.</td>
<td>Requiere gestión de caché. No es adecuado para la decisión de subsegundos.</td>
<td>El desempeño de las consultas se basa en gran medida en la optimización a través de particiones y distribución de predicados.</td>
</tr>
</tbody>
</table>

### Enfoque híbrido

Las arquitecturas híbridas permiten a los arquitectos anclar conjuntos de datos críticos en Data 360 para una gobernanza centralizada mientras aprovechan las consultas federadas para una actualización, una duplicación reducida y un acceso ampliable a grandes conjuntos de datos externos. Este enfoque equilibra las E/S, calcula la localidad, el costo y los requisitos de cumplimiento.

#### Casos de uso híbridos

Utilice un enfoque híbrido para una gobernanza equilibrada, frescura y eficiencia operativa combinando el ingreso de datos y la copia cero para entregar perspectivas con capacidad de acción en tiempo real. Utilice el ingreso para conjuntos de datos regulados de alto valor donde se requiere trazabilidad, RLS y enmascaramiento, y la federación para conjuntos de datos efímeros o de gran volumen donde la actualización y el desempeño son clave.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Data Ingestion and Zero Copy - Copy of Hybrid.png" alt="Descripción general de enfoque híbrido" />

#### Libro de jugadas de arquitecto

- **Casos de uso**
  - **Participación de OmniCanal:** Combine datos históricos de clientes con comportamiento en tiempo real para entregar experiencias coherentes y contextuales.
  - **Oportunidades en curso de IA/ML:** Entrene modelos en conjuntos de datos canónicos depurados mientras los enriquece con señales sin procesar o en tiempo real procedentes de fuentes externas.
  - **Necesita cumplimiento y agilidad mixtos:** Aplique una regulación estricta para datos confidenciales pero federe para agilidad operativa.
- **Escenarios industriales**
  - **Retail:** Utilice el ingreso para la resolución de identidad y la unificación de perfiles; federe para ofertas en tiempo real y personalización.
  - **Cuidados sanitarios:** Mantenga registros de pacientes dorados a través del ingreso mientras federa transmisiones de dispositivos IoT y datos de sensores para contexto inmediato.
  - **Servicios financieros:** Ingrese datos regulados en un lago regulado por el cumplimiento mientras federa consultas externas para la detección de fraude y el monitoreo de riesgos.
- **Prácticas de diseño**
  - **Ancle la gobernanza con el ingreso:** Ingrese datos de alto valor o regulados en modelos canónicos para garantizar Trust y cumplimiento.
  - **Utilizar Federation for Freshness:** Permita a los lagos externos proporcionar acceso a datos en tiempo real o a gran escala sin duplicación.
  - **Equilibrar costo frente a Desempeño:** Perfil de cargas de trabajo para decidir qué ingresar frente a federar, minimizando los costos de almacenamiento o consulta innecesarios.
  - **Aplicar gobernanza por capas:** Aplique la regulación centralizada para datos ingresados, mientras aprovecha los propios controles de seguridad de sistemas federados (por ejemplo, RLS, enmascaramiento).
  - Cuando diseñe oportunidades en curso híbridas, garantice el ingreso incremental para conjuntos de datos históricos y envíe agregaciones o filtros a orígenes federados para optimizar la E/S y calcular el uso.
- **Consideraciones de costos**
  - Optimice el costo total frente al desempeño combinando el ingreso para el cumplimiento o los datos críticos con la federación cuando sea necesaria la actualización.
  - Tenga en cuenta las E/S y calcule la distribución al mezclar el ingreso y la federación. Para reducir el costo de computación en sistemas de origen de consultas repetidas, utilice el almacenamiento en caché (Consulta acelerada) para conjuntos de datos federados de alta lectura y acceso frecuente.

## Guía de decisiones de casos de uso

A continuación se muestran arquetipos comunes que ilustran cómo aplicar esta lógica.

1. **El arquetipo "Fuente única de la verdad": Centralizar y gobernar**
   - **Escenario:** Necesita crear perfiles Customer 360 unificados que cumplan los requisitos para toda su compañía global. Los datos proceden de una docena de sistemas diferentes, deben cumplir con las estrictas leyes de RGPD y CCPA y servirán como la fuente de confianza para todas las interacciones de marketing y servicio.
   - **Patrón recomendado:** **Ingreso de datos.** La prioridad es la gobernanza, Trust y Control. El ingreso de los datos en Data 360 es la única forma de crear un perfil canónico completamente auditable que esté aislado de los sistemas de origen.
2. **El arquetipo "Perspectivas en tiempo real": Analizar sin moverse**
   - **Escenario:** Su equipo de ciencia de datos necesita ejecutar consultas exploratorias en una tabla de transacciones masiva y en constante actualización en Snowflake. Al mismo tiempo, su equipo ejecutivo desea un tablero de BI en vivo con esos mismos datos. Mover petabytes de datos diariamente es demasiado lento y costoso.
   - **Patrón recomendado:** **Zero Copy Federation.** La prioridad es la velocidad, la agilidad y la rentabilidad a escala. Cero copia le permite aprovechar el inmenso poder de su almacén de datos existente para consultas en tiempo real sin la sobrecarga y la latencia de la duplicación de datos.
3. **El arquetipo "Inteligencia híbrida": Gobernar el núcleo, federar el borde**
   - **Escenario:** Desea enriquecer sus perfiles de clientes gobernados e ingresados con señales de comportamiento en tiempo real (como clics de sitios web) desde un lago de datos. Necesita la estabilidad del perfil principal pero la inmediatez de los datos en vivo para potenciar la personalización en el momento.
   - **Patrón recomendado:** **Un enfoque híbrido.** Utilice el ingreso de datos para crear el núcleo estable y regulado de sus datos de clientes. Luego utilice Cero copia para federar los datos volátiles en tiempo real, uniéndolos en el momento de la consulta para una vista completa al segundo.

## El camino a seguir

La estrategia de datos de compañía ya no se trata de elegir un patrón de integración único: se trata de diseñar flexibilidad controlada dentro de un ecosistema de datos interoperable. La selección del método de integración de datos correcto para cada sistema de datos de origen en base a las necesidades de negocio a menudo lleva a un enfoque híbrido que combina los puntos fuertes del ingreso de datos y la federación de datos.

- Ingrese conjuntos de datos gobernados de misión crítica en Salesforce Data 360 para el cumplimiento, la resolución de identidad y los flujos de trabajo operativos.
- Genere datos a través de Cero copia para análisis en vivo, exploratorios y dirigidos por IA sin duplicar el almacenamiento.

Salesforce Data 360 en Hyperforce ofrece resiliencia y capacidad de ampliación de múltiples regiones. ts open lakehouse with Iceberg tables permite calcular la separación y la interoperabilidad con plataformas como Snowflake, Databricks y S3 Iceberg, formando la columna vertebral de un ecosistema de datos multinube verdaderamente interoperable.

A medida que evolucionan los ecosistemas de datos, equilibre continuamente la frescura, el costo, el desempeño y el cumplimiento para mantener la agilidad arquitectónica. Prepare su plataforma para el futuro unificando datos ingresados y gobernados con acceso federado. Esto permite la inteligencia en tiempo real, la activación de IA y la personalización a escala de compañía entre nubes, regiones y dominios de negocio.

Las soluciones únicas no se adaptan a la mayoría de los negocios. La estrategia óptima asigna el patrón correcto al controlador de negocio correcto.

## Acerca de los autores

Yugandhar Bora es Arquitecto de Ingeniería de Software en Salesforce, especializado en arquitectura de datos dentro de la plataforma Aplicaciones de inteligencia y datos. Lidera iniciativas de la junta de revisión de arquitectura de negocio (EARB) centradas en la gobernanza de datos y modelos de datos unificados, mientras contribuye a soluciones de aprovisionamiento de plataforma automatizadas.

Jan Fernando es Arquitecto principal en la Oficina del Arquitecto jefe de Salesforce. Se unió a Salesforce en 2012, aportando una gran experiencia desde su época en el ecosistema de startups. Antes de incorporarse a la Oficina del Arquitecto Jefe, pasó más de una década en la organización Platform, donde dirigió varias transformaciones tecnológicas clave.

<!-- document id=521a7110c40d39516e6931f00c7b4f96ee3bda76efd33973c44d075344122b1d url=/architect/next/es-mx/decision-guides/guides/step-based-async-framework.md -->

## Descripción general

Las arquitecturas modernas de Salesforce están cada vez más impulsadas por el procesamiento asíncrono; no como una comodidad, sino como un requisito estratégico para la escala. En los últimos años, hemos visto a más y más compañías lidiar con volúmenes de datos crecientes, integraciones complejas que implican múltiples puntos de contacto y el auge de sistemas autónomos que se ejecutan 24/7/365. Todo esto empuja a los arquitectos hacia el diseño de sistemas que son asíncronos en primer lugar.

El procesamiento asíncrono en Salesforce a menudo significa diseñar alrededor de límites reguladores y complejidad. Esos límites actúan como barandillas y restricciones arquitectónicas que ayudan a producir sistemas escalables y seguros en masa. Aunque ningún límite de plataforma sirve directamente para gestionar la complejidad, los [patrones de diseño](https://refactoring.guru/design-patterns) pueden ayudar a mitigar el riesgo en ese frente. Internamente, Salesforce a menudo amplía los límites de la plataforma para probar nuevas funciones y automatizar procesos de negocio complejos. Construimos un Marco de trabajo de procesamiento asíncrono basado en pasos para ejecutar trabajos asíncronos con un número arbitrario de pasos. Cada paso puede ejecutarse, reintentarse y reiniciarse de forma independiente con controles de gobernanza compartidos y visibilidad operativa completa a través del registro centralizado. Este documento describe sus componentes arquitectónicos clave: Apex y finalizadores colocables en cola, Flujo programado, Cursores Apex, Acciones invocables e integraciones con Slack. Juntos, estos componentes proporcionan una arquitectura modular, ampliable y observable adecuada para necesidades de negocio en evolución.

## Conclusiones clave

- Las arquitecturas modernas de Salesforce deben adoptar un enfoque asíncrono primero para alcanzar la escala, la resiliencia y la transparencia operativa.
- Dividir el trabajo complejo en pasos ejecutables de forma independiente permite un desempeño predecible, reintentos más seguros, puntos de control, reversión y evolución modular sin volver a diseñar flujos de trabajo principales.
- El marco de trabajo proporciona una alternativa ampliable a trabajos por lotes monolíticos y antiguos, llamadas asíncronas encadenadas y flujos profundamente anidados, y está construido para cargas de trabajo de gran volumen que deben ampliarse horizontalmente dentro de Salesforce sin orquestación fuera de la plataforma.
- La ejecución determinista y observable garantiza el seguimiento del progreso, el monitoreo de SLA, el diagnóstico de fallos y la transparencia a nivel de auditoría a través del registro y la gobernanza centralizados.
- Diseñado para el rigor de nivel de compañía, incluyendo la gobernanza unificada, el cumplimiento y el control de estado distribuido entre procesos de negocio de larga duración.

## Mejores prácticas de plataforma

Antes de revisar los requisitos, estos son algunos de los aspectos que se deben y no se deben tener en cuenta para cuándo utilizar un marco como este. Sobre todo, considere qué sistema es la única fuente de verdad. Si su organización de Salesforce depende mínimamente de datos externos pero necesita ampliarse de cientos a millones de registros, considere un marco de trabajo asíncrono basado en pasos.

**Sí** utilice este marco de trabajo si:

- La mayoría (o toda) la información sobre la que actuar ya existe en su CRM.
- El costo inicial o continuo de mantener un trabajo Extraer carga de transformación (ETL) para armonizar datos externos es demasiado alto.
- Debe aplazar el procesamiento de un gran número de registros de Salesforce en una programación establecida.
- Puede desglosar el procesamiento en pasos discretos. Por ejemplo, puede crear un conjunto de registros jerárquicos o basados en árboles, especialmente si el volumen de datos se desvía de la jerarquía o el árbol.

**No** utilice este marco de trabajo si:

- La creación o actualización de registros requiere un nuevo cálculo inmediato.
- La integración es un reto porque los sistemas externos alojan datos principales para actualizaciones de registros. (Considere el envío de datos actualizados a Salesforce con la API masiva.)

Con esas prácticas en mente, revisemos nuestros requisitos y comencemos a construir.

## Desglose de los requisitos

Considere la declaración de problema:

> Dado un trabajo que necesita ejecutarse diariamente, compruebe si ciertos registros cumplen criterios preestablecidos para un procesamiento posterior. Si lo hacen, inicie esos trabajos de procesamiento. Procesar registros podría significar extraer datos de múltiples sistemas externos para realizar cálculos. Los pasos en trabajos deben notificar a las personas a través de Slack que los registros procesados están listos para su revisión. Los pasos también deben distribuir notificaciones a gestores y superiores en la jerarquía de funciones basándose en un retraso configurable después de la primera ronda de notificaciones.

Este problema implica varios pasos diferentes, algunos de los cuales pueden producirse independientemente entre sí. Existen muchas formas de dividir el trabajo. Esta es una agrupación:

- El programador.
- La interfaz de pasos e implementaciones concretas que procesan registros (independientemente del tipo de procesamiento).
- El procesador que organiza los pasos.
- El Apex Invocable llamado por el programador.
- La pieza de notificación. Utilizamos el [SDK Apex Slack](https://developer.salesforce.com/docs/platform/salesforce-slack-sdk/guide/overview.html).
  - Existe cierta complejidad oculta en la frase “retraso configurable”. Revisaremos esta complejidad más adelante en este artículo.

Este es un diagrama con opiniones para el marco de trabajo construido:

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/step-based-async-framework/step-processor.png" alt="Diagrama arquitectónico que muestra Flow Scheduler, procesamiento asíncrono Apex y diferentes implementaciones de pasos posibles" />
Ahora, desglose ese diagrama y comience a construir las piezas.

## Programación con flujo programado

Flujo programado ofrece varias ventajas como mecanismo de programación:

- Los flujos programados se pueden empaquetar e implementar como metadatos. Esto no es cierto para trabajos programados mediante Apex (o a través de la página Trabajos programados).
- El elemento Espera es crítico para marcos de trabajo que requieren llamadas. Al utilizarlo en Flujo, las llamadas no son necesarias en la parte invocable del marco de trabajo.
- La granularidad de la programación cumple los requisitos: el intervalo mínimo para Flujos programados es diario. Si necesita una frecuencia más alta (por ejemplo, cada hora), reconsidere Flujo programado para este requisito.

Otra consideración al configurar el Flujo programado es la apertura de puertas de entorno. Antes de invocar la acción Apex, agregue un elemento Decisión que evalúe la variable `{!$Api.Enterprise_Server_URL_100}`. Esto garantiza que el trabajo se ejecute solo en los entornos previstos, como UAT y Producción. Este patrón es importante porque los entornos sandbox se actualizan con frecuencia o se crean recientemente durante el SDLC, y sin una comprobación de entorno explícita, un Flujo programado podría ejecutarse de forma no intencionada en entornos donde el marco no está destinado a ejecutarse. El uso del operador `contains` en el elemento Decisión hace que la configuración sea resistente a futuras creaciones de sandbox o cambios de URL.

Finalmente, considere cómo debe capturar el marco los fallos. Agregue siempre una ruta de fallo cuando Flow llame a cualquier acción; por ejemplo, puede transferir fallos a la acción "Agregar entrada de registro" de [Nebula Logger](https://www.nebulalogger.com/). Nebula Logger escribe registros en objetos personalizados, de modo que los clientes deben saber que los datos de registro consumen almacenamiento de la organización; de forma predeterminada, los registros se almacenan durante 14 días en una organización y luego se limpian; este periodo de retención es configurable. Nebula Logger también utiliza Eventos de plataforma para publicar registros, de modo que las entradas de registro se guardan independientemente de la transacción de procesamiento de datos principal; esto garantiza la captura de fallos incluso si la acción principal Flujo o Apex se revierte. Los clientes deben evaluar el volumen de registro esperado y los requisitos de retención cuando consideren la incorporación de un marco de trabajo de registro.

Este es el aspecto del flujo:

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/step-based-async-framework/scheduled-flow.png" alt="Flujo programado que contiene un elemento Decisión para su ejecución o no, un elemento Pausa para permitir llamadas y la acción Apex Invocable llamada junto con la ruta de fallo del Registrador de nebulosas" />

Pasemos a los primeros fragmentos de código Apex con el requisito de programación ahora satisfecho.

## Creación de una interfaz de pasos

Definir una interfaz de `Step`:

```java
 public interface Step {
  void execute();
  void finalize();
  String getName();
  Boolean shouldRestart();
}
```

Para este artículo, la interfaz de `step` se muestra como una clase externa para mayor claridad. El marco en sí es flexible: los equipos pueden organizar la interfaz y sus implementaciones utilizando cualquier patrón de empaquetado Apex que prefieran, siempre que todas las clases Paso hagan referencia a la misma interfaz.

Existen algunas cosas a tener en cuenta acerca de los métodos definidos en nuestra interfaz:

- `execute`, aunque sin argumentos por el momento, mejora cuando pasamos una clase de `State` (o interfaz) para orquestar datos entre pasos cuando el pedido importa.
- Los `getName` podrían devolver un valor de `System.Type` en vez de un `String`. El objetivo es proporcionar a la capa de orquestación una forma de registrar nombres de pasos sin exponer otras propiedades.

Esta es la primera implementación concreta que muestra cómo se ajustan estas piezas. Con una excepción más adelante, recomendamos utilizar Apex colocable en cola para implementar el procesamiento asíncrono en Apex; Apex por lotes es normalmente innecesario (y se desaconsejan los métodos de `@future`). Apex colocable en cola se inicia rápidamente y, con Apex Cursors, tiene muchas ventajas sobre Apex por lotes.

### Una implementación similar a un cursor de Apex

Los [cursores Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_cursors.htm) ofrecen una alternativa moderna al modelo Apex por lotes tradicional. Al igual que el procesamiento por lotes, una implementación de Cursor puede obtener registros en partes (hasta 2.000 por lote). Sin embargo, los Cursores permiten múltiples recuperaciones en una sola transacción, lo que permite un rendimiento significativamente superior para operaciones de gran volumen.

Al adoptar Cursores como parte de este marco de trabajo, los equipos deben tener en cuenta las limitaciones de prueba y simulabilidad actuales. El comportamiento del cursor en las pruebas puede diferir del comportamiento de producción, por lo que es importante diseñar estrategias de prueba que eviten depender de los elementos internos del cursor y que validen la lógica de orquestación en los límites. A medida que evolucione la plataforma, estas áreas seguirán mejorando, pero la orientación principal sigue siendo: Los cursores proporcionan un desempeño superior y una carga de orquestación reducida en comparación con Apex por lotes para muchos casos de uso.

Para definir un límite claro entre el Cursor proporcionado por el sistema y su propio código, recomendamos crear una representación similar a Cursor al implementar la interfaz de `Step`. Considere este código:

```java
public inherited sharing abstract class CursorStep implements Step {
  private static final Integer MAX_CHUNK_SIZE = 2000;

  protected Cursor cursor;

  private Integer chunkSize = System.Limits.getLimitDMLRows();
  private Integer position = 0;

  protected abstract Cursor getCursor();
  protected abstract void innerExecute(List<SObject> records);

  public abstract String getName();

  public virtual CursorStep withChunkSize(Integer chunkSize) {
    this.chunkSize = chunkSize;
    return this;
  }

  public void execute() {
    this.cursor = this.cursor ?? this.getCursor();
    this.cursor.setFetchesPerTransaction(this.getFetchesPerTransaction());
    List<SObject> records = new List<SObject>();
    if (this.shouldAdvance()) {
      records = this.cursor.fetch(this.position, this.chunkSize);
      this.position += this.chunkSize;
    }
    this.innerExecute(records);
  }

  public virtual void finalize() {
    Logger.info('finished cursor step for ' + this.getName());
  }

  public virtual Boolean shouldRestart() {
    return this.position < this.cursor.getNumRecords();
  }

  protected virtual Integer getFetchesPerTransaction() {
    Integer maxRecordsPerFetchCall = 2000;
    if (this.chunkSize < maxRecordsPerFetchCall) {
      return this.chunkSize;
    }
    // Integer division rounds down
    // which is perfect for our use-case
    return this.chunkSize / maxRecordsPerFetchCall;
  }

  protected virtual Boolean shouldAdvance() {
    return true;
  }
}
```

Observe la clase de `Cursor`. Los cursores Apex son instancias de `Database.Cursor`, pero nuestra implementación de `Cursor` nos da flexibilidad sobre las deficiencias de Cursores. Esta es la implementación:

```java
public virtual without sharing class Cursor {
  private static final Integer MAX_FETCHES_PER_TRANSACTION = Limits.getLimitFetchCallsOnApexCursor();

  @TestVisible
  private static Integer maxRecordsPerFetchCall = 2000;

  private Integer cursorNumRecords;
  private Integer fetchesPerTransaction = MAX_FETCHES_PER_TRANSACTION;
  private final Database.Cursor cursor;

  public Cursor(
    String finalQuery,
    Map<String, Object> bindVars,
    System.AccessLevel accessLevel
  ) {
    try {
      this.cursor = Database.getCursorWithBinds(finalQuery, bindVars, accessLevel);
    } catch (FatalCursorException e) {
      Logger.newEntry(
        System.LoggingLevel.WARN,
        'Error creating cursor. This can happen if there' +
          ' are no records returned by the query: ' + e.getMessage()
      );
    }
  }

  public Cursor setFetchesPerTransaction(Integer possibleFetchesPerTransaction) {
    // Handle accidental round downs from Integer division
    if (possibleFetchesPerTransaction == 0) {
      return this;
    }
    if (possibleFetchesPerTransaction > MAX_FETCHES_PER_TRANSACTION) {
      Logger.newEntry(
        System.LoggingLevel.DEBUG,
        'Fetches per transaction: ' +
          possibleFetchesPerTransaction +
          ' exceeded platform max fetches per transaction: ' +
          MAX_FETCHES_PER_TRANSACTION +
          ', defaulting to platform max'
      );
      possibleFetchesPerTransaction = MAX_FETCHES_PER_TRANSACTION;
    }
    this.fetchesPerTransaction = possibleFetchesPerTransaction;
    return this;
  }

  @SuppressWarnings('PMD.EmptyStatementBlock')
  protected Cursor() {
  }

  public virtual List<SObject> fetch(Integer start, Integer advanceBy) {
    if (this.getNumRecords() == 0) {
      Logger.newEntry(
        System.LoggingLevel.DEBUG,
        'Bypassing fetch call, no records to fetch'
      );
      return new List<SObject>();
    }
    Integer localStart = start;
    List<SObject> results = new List<SObject>();
    while (
      Limits.getFetchCallsOnApexCursor() < this.fetchesPerTransaction &&
      results.size() < this.getNumRecords() &&
      localStart < start + advanceBy
    ) {
      Integer actualAdvanceBy = this.getAdvanceBy(localStart, advanceBy);
      results.addAll(this.cursor?.fetch(localStart, actualAdvanceBy) ?? new List<SObject>());
      localStart += actualAdvanceBy;
    }
    return results;
  }

  public virtual Integer getNumRecords() {
    this.cursorNumRecords = this.cursorNumRecords ?? this.cursor?.getNumRecords() ?? 0;
    return this.cursorNumRecords;
  }

  protected Integer getAdvanceBy(Integer start, Integer advanceBy) {
    Integer possibleFetchSize = Math.min(advanceBy, this.getNumRecords() - start);
    if (possibleFetchSize > maxRecordsPerFetchCall) {
      Logger.newEntry(
        System.LoggingLevel.DEBUG,
        'Fetch size: ' +
          possibleFetchSize +
          ' exceeded platform max fetch size of ' +
          maxRecordsPerFetchCall +
          ', defaulting to max fetch size'
      );
      possibleFetchSize = maxRecordsPerFetchCall;
    } else if (possibleFetchSize < 0) {
      possibleFetchSize = 0;
    }
    return possibleFetchSize;
  }
}
```

Para el resto de este artículo, omitimos las declaraciones de `sharing` al hacer referencia a clases Apex. En la práctica, asegúrese de que las clases de nivel superior se utilizan explícitamente con o sin colaboración para ajustarse a su modelo de objeto y permisos.

Tenga en cuenta también que nuestra implementación de `Cursor` delega en el `Database.Cursor` de plataforma, con beneficios adicionales discutidos a continuación.

En primer lugar, estas son las pruebas correspondientes:

```java
@IsTest
private class CursorTest {
  @IsTest
  static void itCapsAdvanceByArgument() {
    String accountName = 'helloWorld!';
    insert new Account(Name = accountName);
    String query = 'SELECT Name FROM Account WHERE Name = :bindVar0';
    Map<String, Object> bindVars = new Map<String, Object>{ 'bindVar0' => accountName };

    Cursor instance = new Cursor(query, bindVars, System.AccessLevel.SYSTEM_MODE);

    Assert.areEqual(1, instance.getNumRecords());
    Assert.areEqual(accountName, instance.fetch(0, 1000).get(0).get('Name'));
    Assert.areEqual(1, System.Limits.getApexCursorRows());
  }

  @IsTest
  static void itCapsMaxRecordsPerFetchCall() {
    Cursor.maxRecordsPerFetchCall = 20;
    Integer oneMoreThanMaxFetch = Cursor.maxRecordsPerFetchCall + 1;

    List<Account> accounts = new List<Account>();
    for (Integer i = 0; i < oneMoreThanMaxFetch; i++) {
      accounts.add(new Account(Name = 'Fetch ' + i));
    }
    insert accounts;

    Exception ex;
    List<SObject> results;
    Cursor instance = new Cursor(
      'SELECT Id FROM Account',
      new Map<String, Object>(),
      System.AccessLevel.SYSTEM_MODE
    );
    try {
      results = instance.fetch(0, oneMoreThanMaxFetch);
    } catch (System.InvalidParameterValueException e) {
      ex = e;
    }

    Assert.areEqual(null, ex?.getMessage());
    Assert.areEqual(2, Limits.getFetchCallsOnApexCursor());
    Assert.areEqual(oneMoreThanMaxFetch, results.size());
  }

  @IsTest
  static void itFetchesMultipleTimesPerTransactionWhenMoreThanMaxFetch() {
    Cursor.maxRecordsPerFetchCall = 20;
    List<Account> accounts = new List<Account>();
    Set<String> expectedFetchNames = new Set<String>();
    for (Integer i = 0; i < Cursor.maxRecordsPerFetchCall + 1; i++) {
      String accountName = 'Fetch' + i;
      expectedFetchNames.add(accountName);
      accounts.add(new Account(Name = accountName));
    }
    insert accounts;

    Integer oneMoreThanMaxFetch = Cursor.maxRecordsPerFetchCall + 1;
    Cursor instance = new Cursor(
      'SELECT Name FROM Account',
      new Map<String, Object>(),
      System.AccessLevel.SYSTEM_MODE
    );
    List<SObject> results = instance.setFetchesPerTransaction(2).fetch(0, oneMoreThanMaxFetch);

    Assert.areEqual(Cursor.maxRecordsPerFetchCall + 1, results.size());
    Assert.areEqual(2, Limits.getFetchCallsOnApexCursor());
    Set<String> actuallyFetchedNames = new Set<String>();
    for (Account account : (List<Account>) results) {
      actuallyFetchedNames.add(account.Name);
    }
    Assert.areEqual(expectedFetchNames, actuallyFetchedNames);
  }

  @IsTest
  static void itFetchesMultipleTimesPerTransaction() {
    Cursor.maxRecordsPerFetchCall = 1;
    insert new List<Account>{ new Account(Name = 'One'), new Account(Name = 'Two') };

    Cursor instance = new Cursor(
      'SELECT Id FROM Account',
      new Map<String, Object>(),
      System.AccessLevel.SYSTEM_MODE
    )
      .setFetchesPerTransaction(2);
    List<SObject> results = instance.fetch(0, 2);

    Assert.areEqual(2, instance.getNumRecords());
    Assert.areEqual(2, results.size());
    results = instance.fetch(2, 1);
    Assert.areEqual(0, results.size());
  }

  @IsTest
  static void fetchesCorrectAmountOfRecords() {
    List<Account> accounts = new List<Account>();
    for (Integer i = 0; i < 10; i++) {
      accounts.add(new Account(Name = 'Fetch ' + i));
    }
    insert accounts;

    Cursor instance = new Cursor(
      'SELECT Id FROM Account',
      new Map<String, Object>(),
      System.AccessLevel.SYSTEM_MODE
    )
      .setFetchesPerTransaction(10);
    List<SObject> results = instance.fetch(0, 2);

    Assert.areEqual(2, results.size(), '' + results);
    Assert.areEqual(1, Limits.getFetchCallsOnApexCursor());
  }

  @IsTest
  static void doesNotExceedPlatformMaxFetch() {
    List<Account> accounts = new List<Account>();
    for (Integer i = 0; i < 101; i++) {
      accounts.add(new Account(Name = 'Fetch ' + i));
    }
    insert accounts;

    Test.startTest();
    Cursor instance = new Cursor(
        'SELECT Id FROM Account',
        new Map<String, Object>(),
        System.AccessLevel.SYSTEM_MODE
      )
      .setFetchesPerTransaction(100);
    Integer counter = 0;
    List<SObject> results;
    while (counter <= 100) {
      results = instance.fetch(counter, counter + 1);
      counter++;
    }
    Test.stopTest();

    Assert.areEqual(101, counter);
    Assert.areEqual(0, results.size());
  }
}
```

Al hacer que las `Cursor` sean virtuales, las implementaciones de `CursorStep` concretas pueden operar sin un `Database.Cursor` cuando no necesitan iterar un conjunto de registros grande, similar a devolver un `System.Iterable<T>` en vez de un `Database.QueryLocator` en Apex por lotes. Este es un ejemplo:

```java
public abstract class CursorLikeImplementation extends CursorStep {
  private final Cursor cursorLike;

  public CursorLikeImplementation(List<SObject> previouslyRetrievedRecords) {
    this.cursorLike = new CursorLike(previouslyRetrievedRecords);
  }

  public override String getName() {
    return CursorLikeImplementation.class.getName();
  }

  public override Cursor getCursor() {
    return this.cursorLike;
  }

  private class CursorLike extends Cursor {
    private final List<SObject> records;

    public CursorLike(List<SObject> records) {
      super();
      this.records = records;
    }

    public override List<SObject> fetch(Integer position, Integer chunkSize) {
      // clone, to keep the underlying list type
      List<SObject> clonedRecords = this.records.clone();
      clonedRecords.clear();
      for (Integer i = position; i < this.getAdvanceBy(position, chunkSize); i++) {
        clonedRecords.add(this.records[i]);
      }
      return clonedRecords;
    }

    public override Integer getNumRecords() {
      return this.records.size();
    }
  }
}
```

Tenga en cuenta que como esta clase también es abstracta, deja la implementación concreta de `innerExecute` a subclases.

También existe una alternativa a la subclase interna `CursorLike`. Si sabe que las versiones concretas de un paso como este no superarán otros límites reguladores, puede devolver `this.records` desde `CursorLike.fetch` y sustituir la `CursorStep.shouldRestart()` principal para devolver false. Eso le permite iterar sobre una lista limitada solo por el límite de pila de Apex de 12 MB por transacción asíncrona.

### Otras posibles implementaciones basadas en pasos

Nuestra implementación basada en cursores nos proporciona mucha flexibilidad al paginar grandes cantidades de datos. La interfaz de `Step`, por su parte, nos proporciona la flexibilidad de describir y encapsular pasos de todo tipo.

Considere un paso basado en flujo:

```java
public virtual class FlowStep implements Step {
  private final Invocable.Action specificFlow;

  private Boolean shouldRestart = false;

  public FlowStep(String specificFlowName, Map<String, Object> inputs) {
    this.specificFlow = Invocable.Action.createCustomAction('flow', specificFlowName);
    this.specificFlow.setInvocations(new List<Map<String,Object>>{ inputs });
  }

  public void execute() {
    List<Invocable.Action.Result> results = this.specificFlow.invoke();
    for (Invocable.Action.Result result : results) {
      if (result.isSuccess()) {
        Map<String, Object> outputParams = result.getOutputParameters();
        Object potentialShouldRestartValue = outputParams.get('shouldRestart');
        // Flow does not enforce Booleans being initialized
        //  so a null check is sadly necessary here
        if (potentialShouldRestartValue != null) {
          this.shouldRestart = this.shouldRestart ||
           Boolean.valueOf(potentialShouldRestartValue);
        }
      } else {
        List<String> errorMessages = new List<String>();
        for (Invocable.Action.Error error : result.getErrors()) {
          errorMessages.add(
            'Error code: ' + error.getCode() +
            ', error message: ' + error.getMessage()
          );
        }
        Logger.error(
          'An error occurred within your auto-launched flow:\n' +
            String.join(errorMessages, '\n\t')
        );
      }
    }
  }

  public virtual void finalize() {
    Logger.info(this.getName() + ' finished processing');
  }

  public String getName() {
    return FlowStep.class.getName() + ':' + this.specificFlow.getName();
  }

  public Boolean shouldRestart() {
    return this.shouldRestart;
  }
}
```

Como los flujos no pueden devolver parámetros de salida que se ajusten a un tipo definido por Apex, comprobamos si hay un parámetro de salida de `shouldRestart` antes de utilizarlo.

Algunos pasos podrían estar marcados con funciones. Puede implementar lógica para decidir qué pasos incluir o utilizar un paso sin operación para una función desactivada. El [patrón Objeto nulo](https://refactoring.guru/introduce-null-object) es una forma común de reducir la complejidad en la capa de orquestación:

```java
@SuppressWarnings('PMD.EmptyStatementBlock')
public class NoOpStep implements Step {
  // The null object pattern is commonly implemented
  // as a singleton to reduce memory consumption
  public static final NoOpStep SELF {
    get {
      SELF = SELF ?? new NoOpStep();
    }
    private set;
  }

  public void execute() {
  }

  public void finalize() {
  }

  String getName() {
    return NoOpStep.class.getName();
  }

  Boolean shouldRestart() {
    return false;
  }
}
```

Ahora tenemos bastantes elementos constructivos con los que trabajar. Veamos la capa de orquestación responsable de iterar sobre pasos.

## Creación de un procesador de pasos

El procesador es un punto de inflexión en la arquitectura. Debemos decidir quién define qué pasos se inicializan y dónde. Las opciones incluyen:

- Haga que el procesador defina qué pasos asignar a la lógica de negocio. Esta opción es sencilla, pero se amplía poco para facilitar la lectura.
- Defina la asignación con Metadatos personalizados (CMDT). Los campos Relación de metadatos no admiten `ApexClass`, lo que combina la ortografía de nombres de clases en su configuración de procesos de negocio. Puede reducir el riesgo de administrador convirtiendo el campo en una lista de selección y validando el tipo que existe (`Type.forName()` o consultando `ApexClass`), pero como los registros CMDT no admiten desencadenadores, la validación se produce en tiempo de ejecución. Esta ruta es comprobable, pero los administradores aún pueden crear registros CMDT solo en producción: continúe con cuidado.
- Defina la asignación con registros. Los no administradores pueden configurar pasos, pero las implementaciones se vuelven más difíciles y los entornos pueden desviarse. Proceda con precaución.

Existe una cita famosa de [Clean Code](https://www.oreilly.com/library/view/clean-code-a/9780136083238/) acerca de cómo gestionar esta complejidad en particular:

> La solución a este problema es enterrar la declaración `switch` [para crear objetos] en el sótano de una fábrica abstracta, y nunca dejar que nadie la vea.

Teniendo esto en cuenta, y como nuestro número actual de pasos está bien definido y es poco probable que crezca demasiado, está bien que el procesador de pasos sea también la fábrica de pasos. Esto puede utilizar una enumeración para dirigir la declaración switch:

```java
public enum StepType {
   TYPE_ONE,
   TYPE_TWO,
   TYPE_THREE,
   TYPE_FOUR
   // etc ...
}
```

Y luego para nuestro `StepProcessor`:

```java
public StepProcessor implements System.Queueable, System.Finalizer,
 Database.AllowsCallouts {
  private final List<Step> steps = new List<Step>();

  private Step currentStep;

  public StepProcessor setSteps(List<StepType> stepTypes) {
    for (StepType type : stepTypes) {
      switch on type {
        WHEN TYPE_ONE {
          this.addTypeOneSteps();
        }
        WHEN TYPE_TWO {
          this.addTypeTwoSteps();
        }
        // ... etc
      }
    }
    this.cleanSteps();
    return this;
  }

  public void execute(System.QueueableContext context) {
    this.currentStep = this.currentStep ?? this.steps.remove(0);
    if (context != null) {
      System.attachFinalizer(this);
      Logger.setAsyncContext(context);
    }
    Logger.info('Executing step ' + this.currentStep.getName());
    try {
      this.currentStep.execute();
    } catch (Exception e) {
      Logger.exception('Unexpected exception', e);
    }
    Logger.info('Finished executing step ' + this.currentStep.getName());
    Logger.saveLog();
  }

  public void execute(System.FinalizerContext context) {
    Logger.info('Executing finalizer for step ' + this.currentStep.getName());
    Logger.setAsyncContext(context);
    switch on context?.getResult() {
      when UNHANDLED_EXCEPTION {
        // see the note below about this logging paradigm
        Logger.warn(
          'Failed to run on step' + this.currentStep,
          context?.getException()
        );
      }
      when else {
        this.currentStep.finalize();
        if (this.currentStep.shouldRestart()) {
          this.kickoff();
        } else if (this.steps.isEmpty() == false) {
          this.currentStep = this.steps.remove(0);
          this.kickoff();
        } else {
          Logger.info('Finished executing steps');
        }
      }
    }
    Logger.info(
      'Finished executing finalizer for step ' +
        this.currentStep.getName()
    );
    Logger.saveLog();
  }

  public String kickoff() {
    return this.steps.isEmpty() ? null : System.enqueueJob(this);
  }

  private void cleanSteps() {
    for (Integer reverseIndex = this.steps.size() - 1;
      reverseIndex >= 0; reverseIndex--) {
      if (this.steps[reverseIndex] instanceof NoOpStep) {
        this.steps.remove(reverseIndex);
      }
    }
  }

  private void addTypeOneSteps() {
    this.steps.addAll(
      new List<Step> {
        new ExampleCursorStepOne(),
        new ExampleCursorStepTwo()
      }
    );
  }

  private void addTypeTwoSteps() {
    this.steps.addAll(
      new List<Step> {
        new FlowStep('
          ExampleInvocableName',
          new Map<String, Object>( 'exampleParameter' => true)
        ),
        new ExampleCursorStepThree()
      }
    );
  }
}
```

Los métodos de fábrica mostrados, como `addTypeOneSteps()`, pueden delegar preocupaciones como el marcado de funciones; `cleanSteps()` realiza una comprobación puntual en los pasos recopilados para asegurarse de que no hay ningún paso “vacío” antes de ser verdaderamente asíncrono. Podría tener este aspecto:

```java
private Step getStepOrDefault(String customPermissionName, Step defaultStep) {
  if (System.FeatureManagement.checkPermission(customPermissionName)) {
    return defaultStep;
  }

  return NoOpStep.SELF;
}
```

No hemos debatido el tratamiento de errores desde que mencionamos el Registrador de nebulosas en la sección Flujo programado. Esto se debe a que la `System.Finalizer` nos permite cubrir el registro de todas las condiciones de error sin agregar la gestión de errores específica en cada paso. Cada `Step` se centra en la ejecución, mientras registramos y volvemos a lanzar cualquier ruta insatisfecha de modo que aflore en pruebas de unidad. Esto admite la iteración segura y las alertas a nivel de producción (utilizando el complemento [Slack Logger para Nebula](https://github.com/jongpie/NebulaLogger/tree/main/nebula-logger/plugins/slack) para todos los registros WARN y ERROR).

Una nota acerca del registro de errores: pasar la instancia del paso a mensajes de registro asume un nivel de Trust en lo que se hace visible en los registros. El `toString()` predeterminado para clases Apex incluye todas las propiedades estáticas y a nivel de instancia en el mensaje. Eso puede ser deseable, o puede filtrar información confidencial. Aunque el registro y la seguridad no son el enfoque aquí, tenga en cuenta que para algunos sistemas, la adhesión a una interfaz como `Step` también puede implicar forzar una sustitución para `toString()`.

```java
 public interface Step {
  void execute();
  void finalize();
  String getName();
  Boolean shouldRestart();
  String toString();
}
```

Este método impone a cada creador de objetos la responsabilidad de decidir qué se puede imprimir, lo que puede ser deseable.

En niveles de registro: a nivel de `StepProcessor`, utilizamos `INFO`, el nivel de no error más alto. A medida que se vuelve más granular en la aplicación, los niveles de registro deben disminuir en consecuencia. Los pasos individuales podrían utilizar `DEBUG` para información de alto nivel, con `FINE`, `FINER` y `FINEST` reservados para resultados cada vez más detallados. El registro es tanto un arte como una ciencia, pero seguir estos principios ayuda a mantener los registros coherentes y útiles.

### Gestión de complejidad adicional dentro del procesador de pasos

Antes de continuar, reflexionemos brevemente sobre la decisión de que nuestro procesador de pasos aloje la lógica para la que se utilizan los pasos. En una base de código grande, considere hacer que los `StepProcessor` sean virtuales o abstractos y haga que las subclases identifiquen pasos específicos para establecer una separación apropiada de las preocupaciones.

## La capa invocable Apex

El programador eventualmente invoca Apex. Con el resto de la configuración completa, la sección Apex invocable puede decidir qué pasos se deben ejecutar y pasar el `List<StepType>` al procesador:

```java
public class DailyJobExecutor {
  @InvocableMethod(label='Execute Daily Job')
  public static void executeJob() {
    Logger.info('Executing daily Job');

    List<StepType> correspondingTypes = new List<StepType>();
    // based on [business logic], determine which step types
    // should be included for any daily invocation

    if (correspondingTypes.isEmpty() == false) {
      try {
        new StepProcessor().setSteps(correspondingTypes).kickoff();
      } catch (Exception ex) {
        Logger.exception('Error starting job', ex);
      }
    }
  }

  Logger.saveLog();
}
```

Esta es una parte sencilla de la ecuación: el uso de registros, datos o lógica para determinar qué tipos de pasos ejecutar. La acción invocable es sencilla porque encapsulamos la complejidad en otro lugar. También nos hemos protegido contra excepciones inesperadas y hemos hecho que cada pieza sea fácil de probar de forma aislada.

## Gestión de retrasos antes de llamar a Slack

El [SDK Apex Slack](https://developer.salesforce.com/docs/platform/salesforce-slack-sdk/guide/overview.html) está más allá del ámbito de este artículo, pero un posible inconveniente de los requisitos merece una revisión: notificar a las personas en la jerarquía de funciones basándose en un retraso configurable. Sobre el papel, esto es sencillo y es posible que considere (correctamente) `System.enqueueJob(this)` en la `StepProcessor`. Con [System.AsyncOptions](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_System_AsyncOptions.htm), nuestra inclinación inicial era utilizar la sobrecarga de `enqueueJob` para satisfacer este requisito.

Por ahora, sin embargo, la demora máxima a través de `System.AsyncOptions.MinimumQueueableDelayInMinutes` es de 10 minutos. Como el requisito es de 120 minutos, quedan algunas opciones. Un enfoque ingenuo podría tener este aspecto:

```java
public class ExampleDelayedNotifier implements Step {
  private final List<Slack.ChatPostMessageRequest> notifications = new List<Slack.ChatPostMessageRequest>();
  private final Slack.BotClient botClient = Slack.App
    .getAppByKey('some-slack-app-key')
    .getBotClientForTeam('slack team id');

  // account for the initial delay,
  // so 120 - 10 = 110
  private Integer delayMinutes = 110;

  public void execute() {
    if ( this.delayInMinutes > 0) {
      return;
    }

    Integer maximumAllowedCallouts = 100;
    while (this.notifications.isEmpty() == false && maximumAllowedCallouts > 0) {
      this.botClient.chatPostMessage(this.notifications.remove(0));
      maximumAllowedCallouts--;
    }
  }

  public void finalize() {
    this.delayInMinutes -= 10;
  }

  public String getName() {
    return ExampleDelayedNotifier.class.getName();
  }

  public Boolean shouldRestart() {
    return this.delayInMinutes > 0 || this.notifications.isEmpty() == false;
  }
}
```

En la práctica, el retraso se pasaría a esta clase porque el retraso está dirigido por la configuración.

No recomendamos este enfoque a menos que esté seguro de que solo habrá un tipo de notificación retrasada. Se quema en 11 trabajos asíncronos adicionales antes de comenzar (o más, si el retraso aumenta). Ese costo podría estar bien para un trabajo, no para muchos. También necesitaría agregar un método a la interfaz de `Step` de modo que cada paso pueda indicar al procesador cuánto tiempo esperar antes de reiniciar, lo que agrega ruido.

Eso nos deja dos posibilidades interesantes:

- Puede dividir el paso retrasado en su marco de trabajo existente si ya tiene un trabajo de sondeo programado en un intervalo apropiado. También debería estar de acuerdo con que el retraso especificado llegue hasta 15 minutos después (15 minutos es el intervalo de actualización mínimo para una expresión de CRON programada por Apex). Esto coincide aproximadamente con el ejemplo de Apex invocable; la programación se realiza mediante Apex en su lugar. En otras palabras, puede reutilizar la misma arquitectura basada en `Step` para procesar registros basándose en una marca de tiempo “Iniciar después” y decidir qué pasos utilizar basándose en una lista de selección o asignación de lista de selección múltiple a los valores de enumeración de `StepType` mostrados anteriormente.
- De manera alternativa, si está cómodo definiendo una clase de Apex externa adicional, vuelva a Apex por lotes (a diferencia de Apex colocable en cola, que admite clases internas, las clases Apex por lotes deben ser clases externas) utilizando `System.scheduleBatch()`.

Considere el ejemplo de Apex por lotes. Aunque generalmente recomendamos Apex colocable en cola por flexibilidad y control, este es un caso donde Apex por lotes aún reina:

```java
public class DelayedNotifier implements Database.Batchable<Object> {
  private final StepProcessor processor = new StepProcessor();

  public Iterable<Object> start(Database.BatchableContext bc) {
    return new List<Object>();
  }

  @SuppressWarnings('PMD.EmptyStatementBlock')
  public void execute(Database.BatchableContext bc, Object scope) {
    // we don't need to actually do anything in execute,
    //  we just need to start up the processor in finish
  }

  public void finish(Database.BatchableContext bc) {
    try {
      // you can imagine Notifier as an elided,
      // simpler version of the naive implementation
      // we showed above, now only focused on sending messages
      this.processor.setSteps(new List<Step>{ new Notifier() }).kickoff();
    } catch (Exception ex) {
      Logger.exception('Unexpected error', ex);
    } finally {
      Logger.saveLog();
    }
  }
}
```

Luego, en la `StepProcessor`, imagine que el método de `addTypeOneSteps()` mostrado anteriormente se actualiza con este paso retrasado:

```java
public StepProcessor implements System.Queueable, System.Finalizer,
  Database.AllowsCallouts {
  // .... unchanged top of class elided

  private void addTypeOneSteps() {
    this.steps.addAll(
      new List<Step> {
        new ExampleCursorStepOne(),
        new ExampleCursorStepTwo(),
        new DelayedNotifierStep()
      }
    );
  }

  // ...

  private class DelayedNotifierStep implements Step {
    private final DelayedNotifier delayedNotifier = new DelayedNotifier();
    // again — in practice this value would also be passed in
    private final Integer delayInMinutes = 120;

    public void execute() {
      System.scheduleBatch(
        this.delayedNotifier,
        'Delayed notifier: ' + System.now().getTime(),
        this.delayInMinutes
      );
    }

    public void finalize() {
      Logger.debug('Nothing to finalize, batch scheduled');
    }

    public String getName() {
      return DelayedNotifierStep.class.getName();
    }

    public Boolean shouldRestart() {
      return false;
    }
  }
}
```

Aunque normalmente no recomendamos esta cantidad de saltos, este retraso de paso se convierte en otro elemento constructivo reutilizable. Hasta que se permitan demoras más largas en Apex colocable en cola, también representa la forma más sencilla de producir este efecto (sin un mecanismo de sondeo, como se discutió).

## Conclusión

Utilizamos el diseño orientado a objetos para cumplir los requisitos y creamos un sistema que se ampliará mientras equilibra el costo a largo plazo de la construcción y el mantenimiento. Aunque la declaración de pasos y la creación de instancias pueden en última instancia superar su lugar en `StepProcessor`, hay poca deuda técnica adicional aquí. Con `FlowStep`, los administradores y desarrolladores pueden decidir juntos cuándo tienen más sentido las soluciones sin código o procódigo.

Utilizando la interfaz de `System.Finalizer` en el marco de trabajo Colocable en cola de Apex, junto con Nebula Logger, construimos un sistema sólido y comprobable que nos alerta de fallos imprevistos incluso si los pasos futuros carecen de registro explícito. Para nosotros, este sistema está felizmente ajustando números y reduciendo costos y complejidad. También nos ha proporcionado perspectivas valiosas sobre el comportamiento de los Cursores Apex bajo cargas de trabajo reales, ayudándonos a perfeccionar nuestro enfoque mientras mejoramos la función en sí.

Al descomponer cargas de trabajo complejas y de gran volumen en pasos de ejecución modulares, el marco de trabajo de procesamiento asíncrono basado en pasos transforma las restricciones de plataforma en ventajas de ingeniería, permitiendo desempeño, observabilidad y gobernanza predecibles a escala de la compañía. Los pasos pueden configurarse por administradores y desarrolladores, y en cualquier caso, los autores de pasos pueden centrarse de forma segura en la observación de los límites reguladores de plataforma básicos (como filas DML y filas de consulta recuperadas) sin tener que preocuparse por cómo ampliar cada paso.

## Ruta a seguir

Para poner en marcha y adoptar este patrón en implementaciones de negocio, los arquitectos deben:

- **Evalúe automatizaciones existentes** para identificar áreas donde la orquestación asíncrona puede ayudar a mejorar el desempeño y la observabilidad.
- **Divida procesos grandes** en pasos discretos ejecutables de forma independiente con objetivos de procesamiento claros y puntos de autor discretos (como Flujo o Apex).
- **Defina y agrupe tipos de pasos** para acelerar la estandarización y la reutilización de pasos entre unidades de negocio.
- **Pilote el enfoque** con nuevos procesos o automatizaciones existentes. ¡Es posible que se sorprenda al descubrir cuántos casos Edge encontrará de forma gratuita en cuestión de pasos, cuidando su registro integrado y observabilidad!

## Acerca del autor

James Simone es ingeniero de software principal en Salesforce y tiene más de una década de experiencia trabajando en la plataforma. Era cliente de Salesforce (y propietario de productos) antes de pasar al desarrollo, y ha estado redactando inmersiones técnicas profundas sobre Salesforce desde 2019 en [The Joys Of Apex](https://www.joysofapex.com/). Anteriormente publicó artículos en [el blog Salesforce Developer](https://developer.salesforce.com/content-archive?authors=James%20Simone&content-type=Blogs&language=English) y también en [el blog Salesforce Engineering](https://engineering.salesforce.com/author/james-simone/).

<!-- document id=23e29feec8504254f5ab980bf8262438f4cf356567aa2f3d1973d9877b163fba url=/architect/next/es-mx/decision-guides/guides/get-started-data-360-decision-guides.md -->

# Primeros pasos con las guías de decisiones de Data 360

Esta sección proporciona directrices prácticas para tomar decisiones arquitectónicas críticas acerca de Salesforce Data 360, incluyendo estrategias de aprovisionamiento, conectividad de múltiples organizaciones y patrones de integración. Utilice estas guías para diseñar e implementar arquitecturas de datos efectivas que unifiquen datos de clientes y activen funciones con tecnología de IA.

---

## Aprovisionamiento de Data 360

El [aprovisionamiento de datos](/docs/architect/es-mx/decision-guides/guide/data-360-provisioning) 360 cubre decisiones fundamentales al aprovisionar Salesforce Data 360:

- **Selección de organización**: Decida si aprovisionar Data 360 en una organización de producción existente o crear una organización dedicada, teniendo en cuenta la gobernanza, el cumplimiento y el tiempo hasta el valor.
- **Estrategia multiorganización**: Seleccione entre múltiples instancias independientes de Data 360 o utilice Data Cloud One para unificar múltiples organizaciones de Salesforce, equilibrando la autonomía, el cumplimiento y el costo.
- **Data Cloud One Architecture**: Active múltiples organizaciones de compañía para compartir una única instancia de Data 360 con gobernanza centralizada, colaboración de metadatos y paridad de funciones entre organizaciones.
- **Compartición de datos entre organizaciones de Data 360**: Utilice la colaboración de datos sin copia entre instancias independientes para el cumplimiento regional, la colaboración de unidades de negocio o tableros ejecutivos federados.
- **Consideraciones de aprovisionamiento**: Tenga en cuenta la residencia de datos, los modelos de gobernanza, la latencia, la complejidad de la integración, el costo y la preparación de la IA para implementaciones de toda la compañía.

Ayuda a los arquitectos a diseñar estrategias de aprovisionamiento que garantizan la simplicidad, la coherencia de la compañía, el cumplimiento y la capacidad de ampliación para Customer 360, la IA y la innovación entre plataformas.

---

## Interoperabilidad de Data 360

La [interoperabilidad de Data 360](/docs/architect/es-mx/decision-guides/guide/data-360-interoperability) proporciona un marco de trabajo para integrar Data 360 con plataformas externas y lagos de datos:

- **Patrones de ingreso**: de datos Ingreso en tiempo real, transmisión y por lotes para crear conjuntos de datos canónicos gobernados ideales para Customer 360, cumplimiento y gobernanza centralizada.
- **Federación de datos de copia cero**: Consulta en vivo, Consulta acelerada (almacenamiento en caché) y Federación de archivos para acceder a sistemas externos en tiempo real sin duplicaciones, lo que permite la personalización, tableros y cargas de trabajo de IA/ML.
- **Enfoque híbrido**: Combine el ingreso gobernado para conjuntos de datos principales con una federación de copia cero para mayor frescura y capacidad de ampliación, lo que admite la implicación de OmniCanal, acciones dirigidas por Agentforce y análisis de negocio.
- **Marco de decisiones**: Evalúe las compensaciones en latencia, costo, escalabilidad, gobernanza y complejidad para seleccionar el patrón de integración correcto por origen de datos.
- **Libros de jugadas de arquitecto**: Directrices específicas de la industria, prácticas de diseño y consideraciones de costos para escenarios de finanzas, cuidados sanitarios, minoristas y telecomunicaciones.

Guía a los arquitectos en el equilibrio de la frescura de los datos, la gobernanza y la eficiencia de las oportunidades en curso para crear arquitecturas de datos ampliables, interoperables y listas para la IA que admiten cargas de trabajo operativas y analíticas.

<!-- document id=4f4dc32acf77009f8590549e30d8a97e620d8a88dd48f46d9bab57e8e2c3ab19 url=/architect/next/es-mx/decision-guides/guides/async-processing.md -->

## Descripción general de guía

Esta guía le ayudará a evaluar el enfoque correcto para sus requisitos de procesamiento asíncrono en Salesforce Platform. Explica cada enfoque, detallando los puntos fuertes y las limitaciones de cada uno. La mayoría de los enfoques están alineados con una función de producto, pero algunos enfoques utilizan múltiples funciones en coordinación. La guía incluye casos de uso para resaltar cuándo utilizar cada enfoque.

El procesamiento asíncrono proporciona dos beneficios principales para su arquitectura. En primer lugar, aumenta la capacidad de ampliación porque los procesos asíncronos tienen límites reguladores más altos. En segundo lugar, las solicitudes asíncronas se ejecutan en sus propios hilos de modo que los usuarios pueden realizar otro trabajo mientras las tareas asíncronas se ejecutan en segundo plano.

Tenga en cuenta que esta guía se centra exclusivamente en la selección de una tecnología de procesamiento asíncrono en Salesforce Platform. Otros recursos para ayudar a su proceso de decisión se enumeran en la [sección Recursos](#recursos).

## Productos en ámbito para esta guía

<table>
  <tbody>
    <tr>
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: Salesforce Platform logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/salesforce.svg" alt="Plataforma Salesforce"></td>
      <td><a href="https://www.salesforce.com/platform/agentforce-platform">Salesforce Lightning Platform</a> es una plataforma integral dirigida por IA que unifica empleados, agentes de IA autónomos, datos de la compañía y aplicaciones en un único sistema de confianza para mejorar la productividad y la experiencia del cliente. Permite la creación de una "compañía agencia" conectando aplicaciones Customer 360, Data Cloud y Slack para la automatización de extremo a extremo.</td>
    </tr>
  </tbody>
</table>

Este documento no cubre tecnologías en otros ecosistemas como MuleSoft, Informatica, Commerce Cloud, Tableau y Marketing Cloud.

## Comida para llevar

- **Antes de utilizar el procesamiento asíncrono, asegúrese de que sus casos de uso se ajustan al patrón.** Los patrones asíncronos no tienen SLA, están sujetos a múltiples mecanismos reguladores, pueden tener límites de capacidad definidos basándose en licencias y pueden causar retrasos de procesamiento debido a la naturaleza finita de los recursos asignados a infraestructura asíncrona en Salesforce Platform. Tenga en cuenta estas limitaciones cuando utilice el procesamiento asíncrono en escenarios donde un usuario requiere una respuesta del sistema antes de poder continuar con su trabajo.
- **El procesamiento asíncrono con Salesforce no es una solución para necesidades de ampliación ilimitadas.** Salesforce Platform no se amplía infinitamente y los patrones asíncronos están sujetos a limitaciones. El procesamiento asíncrono utiliza hilos, que contienen la información contextual que una CPU necesita para ejecutar una transmisión de instrucciones. Las cadenas pueden ejecutarse en paralelo. El número de hilos disponibles en cualquier CPU es limitado, de modo que la plataforma tiene mecanismos establecidos para utilizar sus hilos disponibles de la forma más eficiente posible. El [mecanismo de control](/docs/architect/es-mx/fundamentals/guide/async-fundamentals#control-de-flujo) de flujo de la plataforma evita que las organizaciones consuman demasiados hilos y afecten negativamente a otras organizaciones. El [algoritmo de uso](/docs/architect/es-mx/fundamentals/guide/async-fundamentals#uso-justo) justo de la plataforma también controla el número de hilos que una organización tiene disponibles para cada tipo de mensaje concreto.
- **Tenga en cuenta eventos que pueden causar cargas extremas.** Cuando diseñe procesos asíncronos, asegúrese de que pueden gestionar de forma predecible picos y pausas de carga de trabajo. Considere cómo gestiona su implementación eventos inesperados, como cortes de energía, y diseñe salvaguardas que mitiguen la pérdida de datos o la pérdida de funciones.

## Comparación de productos

Esta tabla describe las herramientas disponibles para el procesamiento asíncrono con Salesforce. Consulte esta tabla para revisar las características principales de cada herramienta durante su proceso de toma de decisiones. Consulte [Utilizar casos](#casos-de-uso) y [puntos de decisión](#puntos-de-decisión) para obtener ayuda para elegir las herramientas correctas para su arquitectura.

<table style="border-color:white;overflow-x:scroll;">
  <thead>
    <tr>
      <th>Enfoque</th>
      <th>Descripción</th>
      <th>Habilidades requeridas</th>
      <th>Licencias y límites</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Apex colocable en cola</b></td>
      <td>Utilizar para procesos que implican operaciones de base de datos de larga ejecución o llamadas de servicio web externo. Apex colocable en cola ofrece funciones como Id. de trabajo, compatibilidad para tipos no primitivos y encadenamiento de trabajos.</td>
      <td>Código pro</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm">El número de licencias puede aumentar los límites.</a></td>
    </tr>
    <tr>
      <td><b>Apex por lotes</b></td>
      <td>Cree procesos complejos y de larga ejecución que implican millones de registros dividiendo su conjunto de registros y procesándolo en partes gestionables.</td>
      <td>Código pro</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm">El número de licencias puede aumentar los límites.</a></td>
    </tr>
    <tr>
      <td><b>Apex programado</b></td>
      <td>Ejecute Apex a una hora programada definida por una expresión cron. Aunque el acto de programar Apex mediante la expresión cron es un proceso asíncrono, el código subyacente se ejecuta de forma síncrona cuando se inicia el trabajo.</td>
      <td>Código pro</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm">El número de licencias puede aumentar los límites.</a></td>
    </tr>
    <tr>
      <td><b>Llamadas de continuación Apex</b></td>
      <td>Ejecute llamadas desde métodos Apex ejecutándose en un contexto de transacción síncrono.</td>
      <td>Código pro</td>
      <td>No</td>
    </tr>
    <tr>
      <td><b>Ruta asíncrona (Flujos desencadenados por registro)</b></td>
      <td>Ejecute una operación que desea ejecutar en su propio tiempo. Evite errores DML mixtos que se producen cuando actualiza un valor en un registro relacionado que no forma parte del registro que desencadenó un flujo.</td>
      <td>Código bajo</td>
      <td><a href="https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5">El número y el tipo de licencias pueden aumentar los límites.</a></td>
    </tr>
    <tr>
      <td><b>Ruta programada (Flujos después de confirmar)</b></td>
      <td>Ejecute a una hora programada dinámicamente después de un evento desencadenante, como cuando se crea, se actualiza o se elimina un registro.</td>
      <td>Código bajo</td>
      <td><a href="https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5">El número y el tipo de licencias pueden aumentar los límites.</a></td>
    </tr>
    <tr>
      <td><b>Flujos programados</b></td>
      <td>Ejecute un flujo en segundo plano a una hora especificada y con una frecuencia repetida (diariamente, semanalmente o una vez) para realizar acciones en un lote de registros.</td>
      <td>Código bajo</td>
      <td><a href="https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5">El número y el tipo de licencias pueden aumentar los límites.</a></td>
    </tr>
    <tr>
      <td><b>Desencadenadores de eventos de plataforma</b></td>
      <td>Acople Salesforce libremente con sistemas externos y comuníquese entre componentes asíncronos en Salesforce Platform.</td>
      <td>Código bajo + código profesional</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm">Se requiere una licencia complementaria para casos de uso de eventos de plataforma de gran volumen</a></td>
    </tr>
    <tr>
      <td><b>Captura de datos</b></td>
      <td>Capture y procese eventos de cambio de forma asíncrona después de confirmar la transacción de la base de datos.</td>
      <td>Código pro</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_allocations.htm">Se requiere una licencia complementaria para ampliar por encima de la asignación de línea base.</a></td>
    </tr>
    <tr>
      <td><b>API masiva</b></td>
      <td>Inserte, actualice, altere, consulte o elimine muchos registros de forma asíncrona y procese los resultados más adelante.</td>
      <td>Código pro</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.260.0.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_bulkapi.htm">Hay límites.</a></td>
    </tr>
    <tr>
      <td><b>Acciones Lightning</b></td>
      <td>Permita a las páginas Lightning interactuar con el servidor sin forzar a los usuarios a actualizar completamente la página.</td>
      <td>Código bajo</td>
      <td>No</td>
    </tr>
  </tbody>
</table>

## Puntos de decisión

Esta tabla contiene una descripción general de puntos a tener en cuenta cuando decida qué herramienta asíncrona utilizar.

<table>
  <tbody>
    <tr>
      <td><b>Habilidades requeridas</b></td>
      <td>Algunas de las herramientas descritas en esta guía requieren código, mientras que otras se pueden configurar de forma declarativa. Cuando considere sus opciones, piense en los conjuntos de habilidades que tienen los miembros de su equipo. Recuerde que incluso si los desarrolladores están disponibles para su implementación inicial (a través de un socio de implementación, por ejemplo), es posible que tenga que modificar sus soluciones en el futuro. Si su equipo de mantenimiento carece de desarrolladores, una opción de código bajo puede ajustarse mejor.</td>
    </tr>
    <tr>
      <td><b>Tipo de límites de plataforma aplicados</b></td>
      <td>Determine el tipo de <a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm">límites</a> que se aplican a la ejecución. Cuando diseñe sus soluciones, piense cuidadosamente en cómo el volumen y la frecuencia de las transacciones contarán en los límites reguladores para el enfoque elegido cada día. Calcule el número de ejecuciones que se producirán cada día. Asegúrese de que los valores calculados recaen dentro de los límites asociados con sus herramientas seleccionadas.</td>
    </tr>
    <tr>
      <td><b>Latencia</b></td>
      <td>Determine con qué rapidez estarán disponibles los resultados del procesamiento en la plataforma. Para algunos enfoques, los cambios serán casi inmediatos, mientras que para otros pueden ser minutos u horas.</td>
    </tr>
  </tbody>
</table>

## Casos de uso

Cuando selecciona una herramienta para el procesamiento asíncrono, primero evalúe los requisitos de su organización y los recursos disponibles. Su objetivo es seleccionar la herramienta o las herramientas que minimizan los costos de implementación y mantenimiento, pero aún garantizan la escalabilidad y minimizan su probabilidad de limitar las infracciones. Este objetivo depende de las consideraciones técnicas descritas anteriormente, así como de la composición de su equipo.

Considere un proceso de pedido asíncrono en Salesforce. Cuando se guarda un pedido, desencadena un mensaje a un sistema de gestión de almacén externo con instrucciones especiales sobre cómo empaquetar y enviar un artículo. El usuario que realiza el pedido no necesita una respuesta inmediata del sistema de gestión de almacenes, de modo que la solicitud se puede enviar de forma asíncrona. El procesamiento asíncrono permite al usuario continuar su trabajo sin esperar una respuesta.

Para este caso de uso, puede considerar implementar con Apex. Este enfoque solo funcionará si tiene desarrolladores Apex en su equipo que puedan mantener su solución de pro-código. De lo contrario, un enfoque declarativo tiene más sentido. Además, tenga en cuenta que diferentes conjuntos de [límites se](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) aplican a diferentes herramientas.

Esta tabla enumera casos de uso comunes en la columna más a la izquierda, seguidos de una descripción. La columna _Primera opción_ proporciona el enfoque más habitual utilizado para satisfacer dicho caso de uso, junto con la justificación del enfoque Primera opción. Utilice esto como un punto de inicio en su análisis: el enfoque Primera opción puede tener limitaciones que no funcionarán para su caso de uso.

<table>
  <thead>
    <tr>
      <th>Caso de uso</th>
      <th>Descripción</th>
      <th>Enfoque de primera opción</th>
      <th>Justificación</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Procesamiento por lotes de alto desempeño</b></td>
      <td>Cualquier automatización que debe procesar miles o millones de registros de forma eficiente</td>
      <td><b>Apex</b> por lotes</td>
      <td>Apex por lotes proporciona API enriquecidas para la interfaz con la plataforma y para la velocidad sin procesar.</td>
    </tr>
    <tr>
      <td><b>Trabajo de limpieza de datos</b></td>
      <td>Un trabajo que se ejecuta de forma rutinaria, o bajo demanda, que limpia datos. Los ejemplos incluyen la desduplicación, la verificación de direcciones o la consolidación de datos.</td>
      <td><b>Apex</b> por lotes</td>
      <td>Apex por lotes proporciona API enriquecidas para la interfaz con la plataforma y para la velocidad sin procesar.</td>
    </tr>
    <tr>
      <td><b>Trabajo de acumulación nocturno</b></td>
      <td>Trabajo que calcula datos de acumulación al final de un día hábil.</td>
      <td><b>Apex</b> por lotes</td>
      <td>Apex por lotes proporciona API enriquecidas para la interfaz con la plataforma y para la velocidad sin procesar.</td>
    </tr>
    <tr>
      <td><b>Lógica desencadenada por registro</b></td>
      <td>Ejecute lógica en respuesta a una actualización de registro.</td>
      <td><i>Varía</i></td>
      <td>Consulte nuestra guía de decisiones complementarias, <a href="/docs/architect/es-mx/decision-guides/guide/record-triggered">Automatización de registros</a> de eventos desencadenados. Incluye un árbol de decisiones para casos de uso asíncronos, incluyendo Apex colocable en cola, Apex por lotes, Apex programado, Flujo programado, Flujos de ruta asíncronos y Captura de datos de cambios.</td>
    </tr>
    <tr>
      <td><b>Actualizaciones en cascada a través de un gráfico de objeto</b></td>
      <td>Permite que la acción de guardado de un usuario se complete rápidamente, aplazando la ejecución de actualizaciones en cascada a otros objetos de forma asíncrona.</td>
      <td><b>Apex</b> colocable en cola</td>
      <td>Apex colocable en cola tiene potentes funciones de encadenamiento que permiten a la lógica dividir una cadena de actualizaciones en una serie de transacciones asíncronas.</td>
    </tr>
    <tr>
      <td><b>Procesamiento programado específico de registro</b></td>
      <td>Automatización en una fecha futura dinámica específica del registro (por ejemplo, 3 días antes de una fecha de cierre).</td>
      <td><b>Flujo</b> con una ruta programada</td>
      <td>Las rutas programadas proporcionan una solidez única a Flujo, ya que la plataforma gestiona automáticamente la programación, cancelación y reprogramación de estas rutas si cambian los datos del registro.</td>
    </tr>
    <tr>
      <td><b>Invocación de múltiples servicios externos lentos en paralelo</b></td>
      <td>Durante una ejecución síncrona, se invocan múltiples servicios externos en paralelo para optimizar el tiempo de ejecución general.</td>
      <td>Llamadas de continuación <b>de Apex</b></td>
      <td>Permitir que múltiples llamadas de ejecución lenta se ejecuten en paralelo minimiza el tiempo total para completar el trabajo.</td>
    </tr>
    <tr>
      <td><b>Migración de datos de registros desde un sistema externo</b></td>
      <td>Mueva grandes cantidades de registros a Salesforce Platform desde un sistema externo. Un proceso puntual o programado regularmente.</td>
      <td><b> <b>API</b> masiva</b> </td>
      <td>Este es el enfoque más eficiente y orientado a límites para la migración de datos.</td>
    </tr>
    <tr>
      <td><b>Ejecutar lógica adicional en un sistema externo</b></td>
      <td>Patrón de activación y olvido de notificar a un sistema externo de un evento en la plataforma, permitiendo luego a ese sistema procesar el evento de forma asíncrona.</td>
      <td><b>Eventos de plataforma</b> o <b>Captura de datos</b></td>
      <td>Un modelo pub-sub funciona mejor aquí y permite al sistema externo procesar el evento cuando está listo. Consulte <a href="/docs/architect/es-mx/decision-guides/guide/event-driven">Arquitectura dirigida por</a> eventos para obtener más detalles sobre este patrón.</td>
    </tr>
  </tbody>
</table>

La tabla Casos de uso es una guía hacia el enfoque más adecuado para cada caso de uso. Sin embargo, deberá validar cuán bien se ajusta la tecnología First Choice a las necesidades específicas de su caso de uso. En particular, determine si el enfoque elegido puede cumplir los límites reguladores para su organización.

Una vez que haya identificado un enfoque candidato para su caso de uso, la [Guía de fundamentos](/docs/architect/es-mx/fundamentals/guide/async-fundamentals) de procesamiento asíncrono puede ayudarle a examinar completamente la solución.

## Recursos

Estos recursos adicionales pueden ayudarle con su proceso de decisión:

- Profundice en cada una de las tecnologías asíncronas de plataforma: [Fundamentos de procesamiento asíncrono](/docs/architect/es-mx/fundamentals/guide/async-fundamentals)
- Selección entre Apex y Flow para desencadenadores de registros: [Automatización de eventos desencadenados por registros](/docs/architect/es-mx/decision-guides/guide/record-triggered)
- Información sobre patrones de integración asíncronos: [Arquitectura dirigida por eventos](/docs/architect/es-mx/decision-guides/guide/event-driven)