Las integraciones modernas de Salesforce deben admitir mucho más que un simple intercambio de datos. Se espera que potencien experiencias de clientes en tiempo real, coordinen acciones entre múltiples sistemas y operen de forma fiable a escala empresarial, todo ello cumpliendo estrictos requisitos de seguridad y cumplimiento. Por lo tanto, la selección del enfoque de integración correcto es una decisión arquitectónica crítica, no un detalle de implementación. Considere un escenario comercial común. Un cliente completa una compra en una aplicación móvil, desencadenando una comprobación de aptitud en tiempo real para una oferta personalizada. Al mismo tiempo, los datos de transacciones deben registrarse en un sistema ERP, los atributos de clientes actualizarse en Salesforce y los análisis transmitirse a un lago de datos, sin introducir latencia, duplicación de datos o riesgo de cumplimiento. Escenarios como este son ahora típicos en entornos modernos de Salesforce, donde Salesforce rara vez opera de forma aislada y debe integrarse perfectamente con un ecosistema más amplio de aplicaciones y plataformas de datos. Esta guía existe para ayudar a los arquitectos y desarrolladores a diseñar esas integraciones con claridad y confianza. En vez de centrarse en implementaciones de punto a punto, presenta un conjunto de patrones de integración que abordan escenarios empresariales recurrentes, como orquestación de procesos, sincronización de datos y acceso a datos en tiempo real. Cada patrón enfatiza la intención arquitectónica, las compensaciones y los modelos de ejecución, permitiendo a los equipos tomar decisiones de diseño fundamentadas que se amplían y perduran. Dentro de este documento, encontrará:

• Patrones de integración que representan “arquetipos” comerciales comunes entre procesos, datos y escenarios de acceso virtual
• Un marco de trabajo de selección de patrones para ayudar a identificar el enfoque correcto basándose en la intención de integración y el tiempo de ejecución
• Directrices prácticas sobre consideraciones de escalabilidad, resiliencia, gobernanza y seguridad
• Prácticas recomendadas extraídas de implementaciones reales de Salesforce y Data 360 El objetivo de este documento es proporcionar un lenguaje arquitectónico compartido para la integración, ayudando a los equipos a diseñar soluciones que equilibren el rendimiento, la flexibilidad y Trust mientras se alinean con los datos empresariales y las estrategias de gobernanza.

Este documento es para diseñadores y arquitectos que necesitan integrar datos de otras aplicaciones en su empresa con Salesforce Data 360 (anteriormente Data Cloud). Este contenido es una destilación de muchas implementaciones correctas por arquitectos y socios de Salesforce. Para familiarizarse con las funciones y opciones de integración disponibles para la adopción a gran escala de Data 360, lea las secciones Resumen de patrón y Guía de selección de patrón a continuación. Los arquitectos y desarrolladores deben tener en cuenta estos detalles de patrón y prácticas recomendadas durante la fase de diseño e implementación de proyectos de interacción de datos en Data 360. Si se implementan correctamente, estos patrones le permiten llegar a producción lo más rápido posible y tener el conjunto de aplicaciones más estable, ampliable y sin mantenimiento posible. Los propios arquitectos consultores de Salesforce utilizan estos patrones como puntos de referencia durante revisiones arquitectónicas y los mantienen y mejoran activamente. Como con todos los patrones, este contenido cubre la mayoría de los escenarios de integración, pero no todos. Aunque Salesforce permite la integración de la interfaz de usuario (UI), por ejemplo, dicha integración está fuera del ámbito de este documento.

Cada patrón de integración sigue una estructura coherente. Esto proporciona coherencia en la información proporcionada en cada patrón y también facilita la comparación de patrones.

• Nombre: El identificador de patrón que también indica el tipo de integración contenido en el patrón.
• Contexto: Escenario de integración general que aborda el patrón. Contexto proporciona información acerca de lo que los usuarios están intentando lograr y cómo se comporta la aplicación para dar cobertura a los requisitos.
• Problema: Expresado como una pregunta, este es el escenario que el patrón está diseñado para resolver. Lea esta sección para comprender si el patrón es apropiado para su escenario de integración.
• Fuerzas: Las restricciones y circunstancias que hacen que el escenario establecido sea difícil de resolver.
• Solución: La forma recomendada de resolver el escenario de integración.
• Boceto: Un diagrama de secuencia UML que le muestra cómo la solución aborda el escenario.
• Resultados: Explica los detalles de cómo aplicar la solución a su escenario de integración y cómo resuelve las fuerzas asociadas con ese escenario. Esta sección también contiene nuevos retos que pueden surgir como resultado de la aplicación del patrón.
• Barras laterales: Secciones adicionales relacionadas con el patrón que contienen problemas técnicos clave, variaciones del patrón, problemas específicos del patrón, etc.
• Ejemplo: Un escenario del mundo real que describe cómo se utiliza el patrón de diseño en un escenario de Salesforce del mundo real. El ejemplo explica los objetivos de integración y cómo implementar el patrón para alcanzar esos objetivos.

Utilice esta tabla como una tabla de índice para los patrones de integración contenidos en este documento.

Los patrones de integración de este documento se clasifican en tres categorías: datos, procesos e integraciones visuales.

Los patrones de integración de datos en Data 360 abordan el movimiento y la sincronización de datos entre sistemas para garantizar que tanto Data 360 como las plataformas externas albergan información coherente, oportuna y fiable. Estos patrones normalmente gestionan flujos de datos de gran volumen y gran escala y se basan en oportunidades en curso gobernadas que aplican reglas de coherencia de esquemas, seguimiento de linaje y masterización.

• Los patrones de introducción por lotes representan la capa fundamental de incorporación de datos empresariales. La introducción masiva de datos desde servicios de almacenamiento en la nube como AWS S3, Azure Blob o Google Cloud Storage permite cargar grandes conjuntos de datos históricos periódicamente en Data 360 para la resolución de identidad, segmentación y análisis. Del mismo modo, la introducción masiva desde Salesforce Cloud (como Sales, Service o Marketing Cloud) utiliza conectores nativos y transmisiones de datos para incorporar datos de CRM a la capa de datos unificada, garantizando Armonización y continuidad entre sistemas de implicación.
• Los patrones de transmisión e introducción en tiempo real amplían esto capturando datos de eventos de alta velocidad. La introducción dirigida por eventos a través de la API de introducción permite a los sistemas externos transmitir continuamente la actividad de los clientes en Data 360. La introducción de comportamiento web y móvil en tiempo real captura datos de interacciones y transmisiones de clics directamente desde puntos de contacto digitales para dirigir la personalización inmediata. La sincronización de CRM casi en tiempo real a través de las API de transmisión garantiza que los atributos del cliente y las actualizaciones de consentimiento se reflejen rápidamente en los sistemas. La introducción de transmisiones de eventos desde plataformas de mensajería como Amazon Kinesis o Confluent MSK admite oportunidades en curso de alto rendimiento continuas, alineando Data 360 con arquitecturas de eventos empresariales.
• Unified Multi-Org Data Platform with Data Cloud One ejemplifica aún más la integración de datos, proporcionando un entorno consolidado para unificar datos desde múltiples organizaciones de Salesforce y orígenes externos bajo una capa semántica y de gobernanza común. Esto permite a las organizaciones alcanzar la coherencia de datos de toda la empresa, modelos de datos compartidos y análisis ampliables.
• En la fase de activación, los patrones de activación por lotes siguen el mismo principio de integración de datos. Los segmentos depurados en Data 360 se exportan en trabajos programados a plataformas de marketing y publicidad descendentes, como Marketing Cloud, Meta Ads o Google Ads, donde desencadenan la ejecución de campañas. Del mismo modo, los conjuntos de datos se pueden exportar a destinos de almacenamiento en la nube para impulsar oportunidades en curso de análisis externo y ciencia de datos. En todos estos casos de uso, Data 360 actúa como la fuente de la verdad para datos de clientes sincronizados y depurados.

Los patrones de integración de procesos en Data 360 implican desencadenar u orquestar procesos comerciales entre sistemas en tiempo casi real. Estos patrones permiten que Data 360 participe activamente en flujos de trabajo empresariales, permitiendo respuestas contextuales y activación de datos dinámica.

• La activación basada en API On-Demand activa escenarios de implicación en tiempo real. A través de la API de Connect, las aplicaciones personalizadas pueden consultar o activar perfiles de clientes directamente desde Data 360 como parte de procesos operativos, como una consola de agente que recupera perspectivas de perfiles unificados durante una interacción de cliente. La Recuperación completa de perfiles de clientes a través de la API de gráficos de datos admite aplicaciones compuestas y microservicios que se basan en acceso dirigido por API al gráfico de entidad completo de un cliente, permitiendo experiencias dinámicas sin segmentos preestablecidos.
• Las acciones de datos en tiempo real impulsan aún más este enfoque de integración al permitir la capacidad de respuesta inmediata. Cuando se detecta una señal de cliente (como una compra, un envío de formulario o un evento de umbral), Data 360 puede desencadenar acciones como la actualización de un registro de CRM, la invocación de un webhook externo o el inicio de un flujo de trabajo de oferta personalizado. Estos patrones encarnan una verdadera orquestación de procesos, uniendo Inteligencia de clientes en tiempo real con la ejecución operativa automatizada.

Los patrones de integración virtual en Data 360 permiten el acceso en vivo a orígenes de datos externos o federados sin copiar o duplicar datos físicamente. Estas son críticas para empresas que requieren información gobernada y actualizada en el momento de la consulta mientras minimizan el movimiento de datos.

• Inbound Zero Copy Data Federation (Plataformas externas en Data 360) permite a los sistemas externos, como almacenes de datos o lagos de datos, compartir conjuntos de datos con Data 360 a través de conexiones seguras gobernadas (por ejemplo, Colaboración de datos segura de Snowflake). Esto garantiza que Data 360 pueda acceder y operar en datos externos virtualmente, preservando la actualización y eliminando replicaciones innecesarias.
• El uso compartido de datos de copia cero saliente (Plataformas de Data 360 a externas) permite a Data 360 exponer conjuntos de datos depurados para consumo externo, como modelado de IA, inteligencia comercial o análisis avanzado, a través de mecanismos de federación de datos y consulta en vivo seguros. Seleccionar la mejor estrategia de integración para su sistema no es trivial. Existen muchos aspectos a tener en cuenta y muchas herramientas que se pueden utilizar, siendo algunas herramientas más apropiadas que otras para ciertas tareas. Cada patrón aborda áreas críticas específicas incluyendo las funciones de cada uno de los sistemas, el volumen de datos, la gestión de fallos y la transaccionalidad.

Al seleccionar un patrón de integración, comience respondiendo a dos preguntas fundamentales que dan forma al diseño y el comportamiento generales de la integración. ¿Qué está integrando?: Proceso, Datos o Acceso virtual Esta dimensión define el propósito principal de la integración.

• Las integraciones de procesos se centran en orquestar flujos de trabajo comerciales y coordinar acciones entre sistemas.
• Las integraciones de datos se centran en sincronizar, enriquecer o propagar datos entre sistemas.
• Las integraciones virtuales se centran en acceder a datos externos en tiempo real sin copiarlos o persistir en Salesforce o Data 360. Comprender esta intención ayuda a determinar el nivel de orquestación, movimiento de datos y acoplamiento requerido entre sistemas.
• ¿Cómo se debe ejecutar?: El método Síncrono o Asíncrono define el modelo de ejecución de la integración.
• Las integraciones síncronas son en tiempo real y de bloqueo, donde el llamante espera una respuesta inmediata, utilizada habitualmente para escenarios dirigidos por el usuario o de validación.
• Las integraciones asíncronas son no bloqueantes y desacopladas, diseñadas para gestionar procesos de escala, larga ejecución, reintentos y altos volúmenes de datos. Juntas, estas dos dimensiones (intención de integración y tiempo de ejecución) proporcionan un marco claro y coherente para seleccionar el patrón de integración correcto mientras equilibran la experiencia del usuario, la capacidad de ampliación y la resiliencia operativa. Nota: Una integración puede requerir un middleware externo o una solución de integración (por ejemplo, Enterprise Service Bus) dependiendo de qué aspectos se aplican a su escenario de integración.

Esta tabla enumera los patrones y sus aspectos clave para ayudarle a determinar qué patrón se ajusta mejor a sus requisitos cuando su integración es desde Salesforce a otro sistema

Esta tabla enumera los patrones y sus aspectos clave para ayudarle a determinar el patrón que mejor se ajusta a sus requisitos cuando su integración es desde otro sistema a Salesforce.

Esta tabla enumera algunos términos clave relacionados con middleware y sus definiciones con respecto a estos patrones.

La introducción de datos es el primer paso y el más crítico en el ciclo de vida de datos de Salesforce Data 360. Es cómo la información sin procesar de múltiples sistemas externos (CRM, ERP, API web, móviles o de terceros) entra en la plataforma y se convierte en parte de una vista de cliente unificada. El patrón de ingesta correcto depende de lo que necesita el negocio:

• Volumen de datos: cuántos datos se están moviendo a la vez
• Latencia: qué grado de actualización deben tener los datos
• Funciones del sistema de origen: cómo el sistema puede conectar y entregar datos Data 360 admite múltiples modos de introducción para satisfacer estas necesidades: lote para cargas de gran volumen, transmisión para actualizaciones casi en tiempo real, basado en eventos para inmediatez transaccional e introducción de copia cero para acceso instantáneo a datos externos sin moverlos físicamente. Juntos, estos patrones garantizan que cada señal de cliente (ya sea un evento de compra, un registro de transmisión de clics o una actualización de fidelidad) fluya en Data 360 de forma eficiente, segura y en el plazo de tiempo correcto para potenciar análisis de confianza y experiencias dirigidas por IA.

Los patrones de introducción por lotes son la columna vertebral de la incorporación de datos a gran escala en Data 360. Están optimizados para escenarios donde los datos se procesan de forma masiva (normalmente de forma programada o periódica) en vez de de forma continua. Estos patrones son los más adecuados para:

• Cargas de datos históricas para inicializar la plataforma con registros comerciales existentes
• Sincronización regular con sistemas de registro como ERP, almacenes de datos o bases de datos propias
• Utilice casos donde la actualización en tiempo real no es crítica, pero la coherencia, integridad y auditabilidad son La introducción por lotes ofrece un rendimiento predecible y sencillez operativa, lo que la convierte en una opción de confianza para empresas que gestionan terabytes de datos estructurados o semiestructurados. Data 360 proporciona un conjunto de conectores listos para la producción disponibles de forma general que admiten la introducción por lotes de forma nativa. Estos conectores simplifican la configuración de integración, reducen el desarrollo de ETL personalizado y garantizan la calidad y la seguridad de los datos en cada importación. La tabla siguiente resalta los conectores más comunes utilizados para la introducción por lotes a escala empresarial.

Contexto

Este patrón está diseñado para escenarios empresariales que implican introducir grandes volúmenes de datos estructurados, como archivos CSV o Parquet, y activos no estructurados desde lagos de datos centralizados o caídas de archivos programadas. Los orígenes de datos incluyen comúnmente plataformas de almacenamiento en la nube como Amazon S3, Google Cloud Storage (GCS) y Microsoft Azure Blob Storage, donde los archivos se entregan periódicamente como parte de oportunidades en curso de datos ascendentes o exportaciones por lotes.

Problema

¿Cómo puede una organización establecer un proceso fiable, seguro y de alto rendimiento para introducir conjuntos de datos masivos basados en archivos desde su plataforma de almacenamiento en la nube principal en Data 360 de forma predecible y recurrente, sin sacrificar la gobernanza, la capacidad de ampliación o el rendimiento?

Fuerzas

Introducir conjuntos de datos masivos basados en archivos en Data 360 no es un ejercicio de transferencia de datos sencillo: es un reto arquitectónico modelado por restricciones de escala, gobernanza y plataforma.

Volumen y escala de datos: Los conectores de introducción de Data 360 están optimizados para la fiabilidad y la regulación, no el rendimiento masivo arbitrario. Por ejemplo, el conector Amazon S3 admite hasta 100 millones de filas o 50 GB por objeto, cualquiera que sea el límite que se alcance primero. Para empresas con conjuntos de datos históricos que se ejecutan en miles de millones de registros, este límite se convierte en una restricción de diseño clave. Un enfoque de elevación y cambio de una sola fila se vuelve rápidamente inviable, requiriendo estrategias inteligentes de partición, segmentación y orquestación de datos para alcanzar la escala sin alcanzar los límites del conector.

Definición y mantenimiento del esquema: Data 360 requiere definiciones de esquema explícitas para cada canalización de introducción para garantizar la integridad semántica y estructural. En el caso de la introducción de S3, un archivo csv debe definir encabezados de columna y una única fila de datos representativa. Este archivo actúa como el contrato canónico entre el sistema de origen, es decir, almacenamiento en la nube y Data 360. Cualquier desalineación (en nombres de campo, tipos de datos o codificación) puede provocar fallos de introducción o daños de datos silenciosos. Mantener este archivo de esquema en control de versión y aplicar la validación a través de flujos de trabajo de CI/CD o regulación de datos se convierte en una práctica recomendada para entornos de producción.

Convenios de nomenclatura estricta: Data 360 aplica reglas estrictas de nomenclatura de objetos y campos para mantener la coherencia en el gráfico de metadatos.

• Los nombres de objetos deben comenzar por una letra y solo pueden incluir letras, dígitos o guiones bajos.
• Los nombres de campo deben seguir los mismos patrones. Los archivos que infrinjan estas convenciones (por ejemplo, campos que contengan espacios, caracteres especiales o símbolos no admitidos) fallarán en la validación de esquemas durante la introducción. Las empresas deben implementar procesos de higiene de datos previos a la introducción para desinfectar y normalizar las estructuras de archivos entrantes.

Posición de autenticación y seguridad: Cada conexión al almacenamiento externo debe cumplir con estándares de seguridad y cumplimiento de nivel empresarial.

• La autenticación se gestiona habitualmente a través de claves secretas/acceso de AWS o autenticación de proveedor de identidad federado (IdP).
• Las funciones de IAM deben tener un ámbito para aplicar el menor privilegio, permitiendo solo el acceso de lectura a las rutas de almacenamiento especificadas.
• Para un acceso seguro, las direcciones IP salientes deben agregarse directamente a la lista de admisión del sistema de origen. Estos controles por capas garantizan que cada transferencia de archivos funcione dentro de un perímetro auditable de cero Trust, equilibrando el cumplimiento de la empresa con la flexibilidad requerida para la introducción a gran escala.

Solución

Esta tabla contiene soluciones a este problema de integración.

Boceto

Este diagrama ilustra la secuencia de pasos para introducir los datos desde el almacenamiento en la nube en Data 360

En este escenario:

• El administrador configura una conexión al almacenamiento en la nube a través de la interfaz Configuración de Data 360 (especificando autenticación, detalles de depósito, funciones de IAM y lista blanca).
• La interfaz Configuración de Data Cloud se autentica con Cloud Storage Platform, verificando credenciales y acceso.
• El administrador crea una transmisión de datos en Data 360, vinculando la transmisión de datos al objeto/carpeta en Cloud Storage y definiendo la programación de introducción.
• En el desencadenador de programación, la transmisión de datos solicita archivos de origen (por ejemplo, CSV, Parquet) desde Cloud Storage Platform.
• Cloud Storage Platform entrega archivos, incluyendo el schema_sample.csv válido requerido y otros archivos de datos que cumplen con las convenciones de nomenclatura.
• La transmisión de datos transfiere archivos al entorno de organización interno en Data 360.
• Canalizaciones de Data 360 procesa los archivos: Utiliza la definición de esquema de schema_sample.csv Valida la estructura, los nombres de campo y divide la carga si está por encima de los umbrales de introducción (100 millones de filas/50 GB por archivo). Si se detectan archivos de gran tamaño, se lleva a cabo un paso de partición de preprocesamiento (notificado al administrador para la siguiente ejecución) de forma externa.
• Los registros se importan desde la organización en un objeto de lago de datos (DLO).
• Si es necesario y los datos están particionados, utilice el nodo de anexado en una Trasformación de datos por lotes para combinar múltiples DLO.
• Data 360 registra el éxito/fallo, actualiza el estado para la supervisión y señala que los datos están listos para la asignación, Armonización y Unificación.

Resultados

La aplicación de este patrón permite la introducción segura, programada y a gran escala de archivos estructurados o no estructurados desde plataformas de almacenamiento de Enterprise Cloud en Data 360. El proceso es automatizado, ampliable y resistente, entregando datos sin procesar en objetos de lago de datos (DLO) que sirven como la Base para Armonización y Asignación al modelo de datos Customer 360.

Mecanismos de introducción

El mecanismo de introducción depende del conector y la estrategia de programación definida en Data 360.

Gestión y recuperación de errores

La gestión y recuperación de errores son fundamentales para garantizar la fiabilidad en operaciones de introducción de gran volumen.

• Detección de errores: Cada ejecución de transmisión de datos registra errores de introducción (por ejemplo, desajustes de esquemas, daños en archivos o infracciones de nombres) en Supervisión de Data 360. Los administradores pueden revisar y reprocesar lotes con fallos.
• Mecanismo de recuperación: Data 360 mantiene puntos de control para garantizar que los lotes con fallos no corrompen las ingestas anteriores. Los reintentos se pueden configurar después de corregir problemas de origen (por ejemplo, archivos CSV defectuosos).
• Validación de esquema: El archivo schema_sample.csv define los tipos de datos y la estructura. Cualquier cambio desencadena la validación para evitar la desviación silenciosa de esquemas entre ejecuciones.

Consideraciones de diseño idempotentes

La introducción es idempotente por diseño: el reprocesamiento del mismo archivo no da como resultado registros duplicados. Las estrategias clave incluyen:

• Huella de archivo: Data 360 calcula sumas de control para identificar y omitir archivos procesados anteriormente.
• Ingestión transaccional: Los datos se presentan y solo se confirman en el DLO cuando se procesan correctamente todos los registros.
• Anexado vs. Sustituir: Dependiendo de la lógica comercial, las transmisiones pueden anexar o sustituir completamente el DLO de destino; esto garantiza resultados deterministas y evita solapamientos parciales de datos.

Consideraciones de seguridad

La seguridad es integral en todas las oportunidades en curso de introducción, desde la autenticación hasta el cifrado y el control de acceso.

• Autenticación y autorización: Los conectores utilizan el Marco de integración seguro de Salesforce, aprovechando credenciales nombradas y credenciales externas para la autenticación sin exponer secretos.
• Cifrado: Los datos se cifran en tránsito (TLS 1,2+) y en reposo (AES-256).
• Controles de red: Los sistemas de almacenamiento de origen (por ejemplo, depósitos de S3) deben incluir direcciones IP de Data 360 en la lista de admisión.
• Alineación de cumplimiento: Admite marcos de trabajo de protección de datos empresariales como el RGPD, HIPAA y directrices FFIEC cuando se emparejan con Claves gestionadas por el cliente (CMK).
• Auditabilidad: Cada trabajo de introducción y acceso a credenciales se registra para la trazabilidad y los informes de cumplimiento.

Barras laterales

Oportunidad

La puntualidad depende de la programación de introducción y el volumen de datos.

• Los conjuntos de datos de grandes empresas (más de 100 filas) pueden requerir partición para la introducción paralela.
• La latencia de introducción habitual oscila entre minutos y algunas horas, dependiendo del tamaño del archivo y la complejidad de la transformación.
• Para la introducción casi en tiempo real, la transmisión de Data 360 o los conectores basados en API pueden complementar el modelo basado en archivos.

Volúmenes de datos

• Mejor adaptado para la ingesta por lotes periódica de gran volumen.
• Cada objeto procesado a través del conector S3 admite hasta 100 millones de filas o 50 GB por archivo.
• Para sistemas de escala de petabytes, utilice partición de datos y orquestación de múltiples transmisiones.

Capacidad de extremo y compatibilidad de estándares

La capacidad y la compatibilidad estándar para el extremo depende de la solución que seleccione.

Gestión de estado

Se realiza un seguimiento del estado a través de Transmisiones de datos y su última marca de tiempo de ejecución correcta.

• Data 360 mantiene automáticamente los estados de sincronización y las compensaciones, garantizando que solo se procesen archivos nuevos o modificados en ejecuciones posteriores.
• Al integrar con herramientas ETL externas, se recomiendan identificadores de archivo exclusivos (por ejemplo, UUID o marcas de tiempo) para evitar la duplicación.

Escenarios de integración complejos

En arquitecturas empresariales avanzadas, este patrón puede integrarse con:

• Oportunidades en curso de ETL de middleware (por ejemplo, Informatica, MuleSoft): para orquestar el procesamiento previo, la validación y la partición de archivos antes de la transferencia a Data 360.
• Flujos de trabajo IA/ML: los datos de DLO procesados se pueden publicar a través de DMO para modelar entornos de entrenamiento o índices RAG a través de Destinos de activación de Data 360.
• Sistemas transaccionales: los DMO armonizados pueden desencadenar actualizaciones descendentes en Salesforce CRM o sistemas externos a través de Acciones de datos o Eventos de plataforma.

Ejemplo

Una institución financiera global almacena datos de clientes y transacciones en un lago de datos de AWS S3, donde los archivos Parquet particionados se generan cada noche por región (como EE.UU., UE y APAC). El equipo de arquitectura de datos configura múltiples transmisiones de datos en Data 360, cada una conectada a una carpeta regional, con un schema_sample.csv compartido garantizando encabezados y tipos de datos coherentes en todas las particiones. Las programaciones de introducción nocturna cargan automáticamente los datos en DLO, tras lo cual las Transformaciones de datos por lotes anexan todas las particiones regionales en un Customer_Transactions_DLO unificado. Este conjunto de datos armonizado se asigna a continuación al modelo de datos Customer 360, lo que activa el análisis descendente y la activación de IA. El enfoque entrega una introducción automatizada y fiable desde el lago de datos existente, aplica una autenticación y cifrado sólidos alineados con políticas de TI empresariales y proporciona una base modular ampliable que admite la expansión futura y la evolución de esquemas.

Contexto

Un caso de uso principal y crítico para Data 360 es la unificación de datos de clientes en todo el ecosistema de Salesforce. Este patrón cubre la introducción nativa de datos desde plataformas principales de Salesforce: Sales Cloud y Service Cloud (colectivamente Salesforce CRM) y Marketing Cloud Engagement. Los orígenes incluyen objetos CRM estándar y personalizados (por ejemplo, Cuenta, Contacto, Caso, Oportunidad) y extensiones de datos de Marketing Cloud Engagement que albergan eventos de implicación, envíos de correo electrónico y datos de seguimiento.

Problema

¿Cómo puede una organización introducir de forma eficiente y fiable objetos CRM estándar y personalizados y extensiones de datos de Marketing Cloud Engagement en Data 360 de modo que los datos se puedan utilizar para crear perfiles de clientes unificados (resolución de identidad, Customer 360), manteniendo al mismo tiempo el rendimiento, la gobernanza y la interrupción mínima en los sistemas de origen?

Fuerzas

Los conectores nativos simplifican el trabajo, pero se deben gestionar varias fuerzas operativas y arquitectónicas:

• Permisos de origen completos: Un usuario de conexión exclusivo (cuenta de integración) debe tener permisos de lectura a nivel de objeto y campo apropiados. El fallo en la asignación de conjuntos de permisos requeridos (por ejemplo, un conjunto de permisos de conector de Data 360 preconstruido) es una causa común de fallo de introducción.
• Modos de actualización de datos y coste: Los conectores admiten los modos de actualización completa y delta/incremental. Las actualizaciones completas son más pesadas en rendimiento y créditos; los extractos delta reducen la carga pero dependen de un seguimiento de cambios fiable en el sistema de origen.
• Esquema personalizado y asignación de campos: Las instancias de CRM a menudo incluyen objetos/campos personalizados. Se requiere una asignación de esquemas precisa y la gestión de campos personalizados (nombres, tipos) para evitar errores de asignación o desviación semántica.
• Iniciar paquetes de datos frente a Asignación personalizada: Los paquetes de datos de inicio aceleran la incorporación seleccionando previamente objetos/campos típicos, pero las organizaciones altamente personalizadas necesitarán definiciones de transmisiones a medida.
• Límites de API y rendimiento: Los límites de API de la organización de origen y los índices de extracción de Marketing Cloud limitan la agresividad con la que puede programar actualizaciones.
• Convenciones sobre higiene de datos y nomenclatura: Los nombres de campo de origen, el comportamiento nulo y los tipos de datos deben normalizarse antes de la introducción para evitar problemas de asignación descendente.
• Seguridad y privilegios mínimos: El conector se basa en la autenticación segura y debe respetar los patrones de IAM de menor privilegio, la capacidad de auditoría y los controles de red.

Solución

Esta tabla contiene soluciones a este problema de integración.

Boceto

Este diagrama ilustra la secuencia de pasos para introducir los datos desde el almacenamiento en la nube en Data 360

En este escenario:

• El administrador proporciona usuarios de integración y asigna conjuntos de permisos de conector en organizaciones de origen.
• El administrador configura conectores en Configuración de Data 360 (se conecta a Salesforce CRM y Marketing Cloud a través de OAuth/aplicación conectada).
• El administrador crea transmisiones de datos seleccionando objetos y extensiones de datos, selecciona la actualización completa o delta y establece programaciones.
• En ejecución programada, Data 360 solicita tokens de esquema y delta desde la(s) fuente(s).
• Los sistemas de origen devuelven registros (delta o carga completa). Marketing Cloud puede entregar extractos; CRM puede devolver resultados de JSON/Consulta.
• Data 360 organiza archivos en su área de organización segura interna y valida con el esquema asignado.
• Si la validación falla, el error de registro de introducción, las alertas al administrador y detiene la confirmación. Si la validación se realiza con éxito, Data 360 confirma registros atómicamente en el DLO de destino.
• Los registros de supervisión y auditoría se actualizan con el linaje, la duración de la ejecución, los recuentos de filas y el uso de credenciales. Alertas emitidas a administradores si se desencadenan umbrales o errores.

Resultados

Los datos principales de relaciones con clientes e implicación de marketing se introducen en Data 360 como Objetos de lago de datos (DLO). Esto produce:

• Conjunto de datos unificado que contiene perfiles, casos, oportunidades y mediciones de correo electrónico/implicación.
• Fundamento para resolución de identidad y construcción de Perfiles Particulares Unificados.
• Preparación operacional para Armonización descendente, enriquecimiento, modelado de IA y activación preservando al mismo tiempo la gobernanza y la capacidad de auditoría.

Mecanismos de introducción

El mecanismo de introducción depende del conector y la estrategia de programación definida en Data 360.

Gestión y recuperación de errores

La gestión y recuperación de errores son fundamentales para garantizar la fiabilidad en operaciones de introducción de gran volumen.

• Registros por ejecución: Cada ejecución de transmisión de datos proporciona detalles de éxito/fallo y errores a nivel de fila.
• Reintentos y puntos de control: Las ejecuciones fallidas se pueden volver a intentar después de solucionar problemas de origen o esquema; Data 360 utiliza la semántica de ensayo y confirmación atómica.
• Alertas: Configure alertas para desviación de esquema, fallos repetidos o brechas de secuencia delta.

Consideraciones de diseño idempotentes

La introducción es idempotente por diseño: el reprocesamiento de la misma no da como resultado registros duplicados. Las estrategias clave incluyen:

• Detección de cambios: Las extracciones Delta se basan en indicadores de cambio del sistema de origen (LastModifiedDate / Captura de datos de cambio del sistema). Verifique que el origen proporciona marcas de tiempo/marcadores fiables.
• Deduplicación: Utilice claves comerciales exclusivas (por ejemplo, Contact.ExternalId) para deduplicar o alterar en DLO.
• Comprobación transaccional: Los registros se organizan y solo se confirman cuando el procesamiento por lotes se completa correctamente.

Consideraciones de seguridad

La seguridad es integral en todas las oportunidades en curso de introducción, desde la autenticación hasta el cifrado y el control de acceso.

• Autenticación y autorización: Los conectores utilizan el Marco de integración seguro de Salesforce, aprovechando credenciales nombradas y credenciales externas para la autenticación sin exponer secretos.
• Cifrado: Los datos se cifran en tránsito (TLS 1,2+) y en reposo (AES-256).
• Controles de red: Los sistemas de almacenamiento de origen (por ejemplo, depósitos de S3) deben incluir direcciones IP de Data 360 en la lista de admisión.
• Alineación de cumplimiento: Admite marcos de trabajo de protección de datos empresariales como el RGPD, HIPAA y directrices FFIEC cuando se emparejan con Claves gestionadas por el cliente (CMK).
• Auditabilidad: Cada trabajo de introducción y acceso a credenciales se registra para la trazabilidad y los informes de cumplimiento

Barras laterales

Oportunidad

La puntualidad depende de la programación de introducción y el volumen de datos.

• La cadencia ideal depende de las necesidades comerciales: cada hora para desencadenadores de marketing casi en tiempo real, cada noche para grandes reconciliaciones.
• Los modos Delta reducen la carga y el coste; las actualizaciones completas son más pesadas y se utilizan para cargas iniciales o cambios de esquema importantes.

Volúmenes de datos

• Los conectores de CRM están optimizados para conjuntos de datos transaccionales y de medio volumen (millones de registros).
• Para volúmenes históricos extremadamente grandes, considere ETL por etapas para particionar y cargar en etapas.

Capacidad de extremo y compatibilidad de estándares

La capacidad y la compatibilidad estándar para el extremo depende de la solución que seleccione.

Gestión de estado

• Estado conector: Las transmisiones de datos mantienen las últimas marcas de tiempo de sincronización correctas y las compensaciones delta.
• Estrategia de clave principal: Prefiera identificadores comerciales coherentes (Id. externos) de modo que la reconciliación descendente y las alteraciones sean deterministas.

Escenarios de integración complejos

En arquitecturas empresariales avanzadas, este patrón puede integrarse con:

• Topologías híbridas: Combine la introducción de CRM con la transmisión (Eventos de plataforma) para actualizaciones casi en tiempo real.
• Orquestación de middleware: Utilice herramientas MuleSoft o ETL cuando se requiera orquestación compleja, enriquecimiento o introducción previa a la transformación.
• Bucles de comentarios de activación: Los DMO armonizados pueden desencadenar actualizaciones descendentes en sistemas de origen a través de Acciones de datos o API de plataforma (cuidado con los controles de SoD).

Ejemplo

Un minorista multinacional consolida mediciones de implicación de Cuentas, Contactos, Casos, Oportunidades y Marketing Cloud en Data 360 para crear una vista de cliente unificada. El paquete de datos de inicio inicializa objetos principales de Ventas y Servicio, mientras que el equipo amplía el modelo con campos personalizados como Loyalty_Membershipc y Customer_Tierc para capturar el contexto de fidelidad. Las transmisiones de datos de CRM se ejecutan cada hora en modo delta, y Marketing Cloud Engagement se sincroniza diariamente utilizando extractos delta para eventos de implicación. Estos conjuntos de datos se procesan a través de DLO y resolución de identidad, dando como resultado un perfil de cliente unificado que combina CRM y señales de implicación para potenciar la personalización y los modelos de IA descendentes.

Estos patrones se crean para escenarios donde los milisegundos importan, cuando las interacciones, transacciones o señales de los clientes deben desencadenar perspectivas o acciones inmediatas. Van más allá de la introducción por lotes programada tradicional para activar el flujo de datos dirigido por eventos, donde la información se procesa en el momento en que se genera. En el ecosistema de Salesforce Data 360, el “tiempo real” no es un modo único, es un continuo de modelos de latencia. En un extremo se encuentra la sincronización casi en tiempo real, donde las actualizaciones desde sistemas de registro (como CRM o ERP) se reflejan en Data 360 en cuestión de segundos o minutos. En el otro extremo se encuentra la captura de eventos en tiempo real verdadera, donde las señales de comportamiento del lado del cliente (como clics, compras o interacciones móviles) se introducen y activan en milisegundos. Para los arquitectos, la distinción es más que semántica. Define cómo se diseñan las oportunidades en curso, cómo se invocan las API y cómo se toman las decisiones posteriores. La selección del patrón correcto, ya sea sincronización casi en tiempo real o introducción de transmisiones de eventos, garantiza que el sistema cumpla los objetivos de latencia operativa del negocio mientras mantiene la integridad, la capacidad de ampliación y la gobernanza de los datos.

Contexto

Este patrón permite a cualquier sistema externo, como una aplicación personalizada, una plataforma de Internet de las Cosas (IoT), un sistema de punto de venta (POS) o un servicio externo, distribuir de forma programática datos de eventos en Data 360 casi en tiempo real a medida que se producen eventos discretos.

Problema

¿Cómo puede un desarrollador enviar de forma fiable registros únicos o pequeños lotes asíncronos de eventos desde una aplicación externa a Data 360 con baja latencia de modo que los datos estén disponibles rápidamente para su procesamiento, segmentación y activación?

Fuerzas

Este patrón entrega baja latencia y un mejor control del desarrollador, pero introduce varias restricciones técnicas y dependencias operativas:

• Dependencia del desarrollador: Requiere el esfuerzo del desarrollador para implementar clientes de API de REST autenticados y lógica de error/reintento: no es un conector de apuntar y hacer clic.
• Esquema estricto sobre escritura: La API de introducción aplica el esquema sobre escritura. Debe definirse un esquema preciso y cargarse en la configuración del conector; todas las cargas deben ajustarse exactamente o rechazarse.
• Modos de interacción dual: El mismo conector admite tanto la transmisión (JSON) para actualizaciones registro por registro de baja latencia como la masiva (CSV) para sincronizaciones periódicas más grandes: los arquitectos deben elegir por caso de uso.
• Autenticación y seguridad: Las llamadas deben autenticarse a través de una aplicación conectada de Salesforce utilizando OAuth 2.0 (por ejemplo, Flujo de soporte JWT para servidor a servidor). Los ámbitos de gestión de tokens, rotación y privilegios mínimos son obligatorios.
• Visibilidad operativa: Los desarrolladores y equipos de plataforma deben implementar la supervisión de códigos de respuesta, reintentos, colas de letra muerta y alertas de desviación de esquemas.
• Requisito de gráfico en tiempo real: Para una activación instantánea verdadera (segmentación instantánea, asignación de DMO en tiempo real), el Objeto de modelo de datos de destino (DMO) debe formar parte del gráfico de datos en tiempo real; de lo contrario, los eventos atraviesan una canalización de latencia ligeramente superior.

Solución

Esta tabla contiene soluciones a este problema de integración.

Boceto

Este diagrama ilustra la secuencia de pasos para introducir los datos desde la API de introducción en Data 360

En este escenario:

• El sistema externo solicita autenticación a través de OAuth/JWT desde el servidor de autenticación.
• El Servidor de autenticación devuelve el token de acceso a Sistema externo.
• El sistema externo envía la solicitud POST de introducción de datos a la API de introducción de Data 360 con autorización y carga JSON.
• La API de introducción valida el esquema de solicitud y la autenticación a través del módulo Etapa y validación.
• En fallo de esquema/autenticación:
• Error devuelto al sistema externo.
• Rechazo registrado para supervisión y alerta.
• En validación correcta:
• Registros organizados y confirmados en Objeto de lago de datos (DLO).
• Éxito registrado para la supervisión.
• Si se activa, los datos se propagan a Gráfico de datos en tiempo real (DMO) desencadenando flujos de trabajo descendentes.
• De lo contrario, los datos procesados a través de canalizaciones por lotes estándar o de latencia superior.
• La API de introducción confirma el éxito en Sistema externo.
• Los componentes de supervisión alertan al administrador sobre colas de letra muerta, índices de rechazo o problemas de latencia.

Resultados

Los datos de eventos externos se introducen en DLO de Data 360 con baja latencia. Cuando el DMO de destino forma parte del gráfico en tiempo real, los datos están disponibles para segmentación instantánea, flujos de trabajo de agentes, modelos de IA y activación operativa. Esto permite respuestas comerciales rápidas a eventos originados desde cualquier sistema conectado.

Mecanismos de introducción

El mecanismo de introducción depende del conector y la estrategia de programación definida en Data 360.

Gestión y recuperación de errores

• Errores inmediatos (sincronización): Respuestas 4xx para errores de esquema/autenticación: el cliente debe solucionar la carga o el token y reintentarlo.
• Fallos transitorios (asíncronos): Respuestas 5xx: el cliente reintenta con retroceso exponencial y fluctuación.
• Cola de letras muertas (DLQ): Los fallos persistentes se producen en DLQ para la inspección manual y la reproducción.
• Supervisión: Realice un seguimiento del índice de rechazo de esquemas, los fallos de autenticación, los percentiles de latencia y el retraso de DLQ. Alerta sobre umbrales.

Consideraciones de diseño idempotentes

• Clave de impotencia: Cada evento debe incluir una clave de idempotencia/Id. de mensaje exclusivos.
• Estrategia de inserción: Utilice claves comerciales (ExternalId) para evitar duplicados en repeticiones.
• Dedup Window: El arquitecto debe definir plazos de deduplicación y retención para el seguimiento de idempotencia.

Consideraciones de seguridad

La seguridad es integral en todas las oportunidades en curso de introducción, desde la autenticación hasta el cifrado y el control de acceso.

• Autenticación: OAuth 2.0 (JWT Bearer) recomendado para servidor a servidor. Limite los ámbitos a solo la introducción.
• Cifrado: TLS 1.2+ para el transporte; Data 360 aplica el cifrado en tiempo de inactividad.
• Privilegio menor: Las credenciales de Aplicación conectada tienen derechos mínimos; rotar secretos y registros de acceso a instrumentos.
• Gobernanza de carga: Incluya indicadores de consentimiento/consumo en metadatos de eventos; aplique políticas de ABAC/CEDAR inmediatamente después de la ingesta.
• Controles IP / Conexión privada: Cuando sea necesario, restrinja el acceso a través de listas de admisión o utilice Conexión privada para redes privadas.

Barras laterales

Oportunidad

La puntualidad depende de la programación de introducción y el volumen de datos. El JSON de transmisión ofrece una latencia de subsegundo a segundo dependiendo del procesamiento y la configuración del gráfico. El CSV masivo es de minutos a horas. Seleccione basándose en SLA comerciales.

Volúmenes de datos

Los tamaños de eventos individuales deben ser pequeños (< pocos KB). Para productores de alto rendimiento, considere el lote en el productor o el uso de un tampón de transmisión (Kafka/Kinesis) antes de llamar a la API.

Gestión de estado

• Versión de esquema: Mantenga la versión de esquema en metadatos de eventos y utilice la versión de conector al actualizar el contrato de OEA.
• Compensaciones de conector: Data 360 controla la semántica de confirmación; los productores deben realizar un seguimiento de las claves de idempotencia y la última secuencia correcta para una reproducción segura.

Escenarios de integración complejos

En arquitecturas empresariales avanzadas, este patrón puede integrarse con:

• Capa de validación de borde: Utilice middleware para traducir formatos de productores heterogéneos al contrato de OAS requerido, realizar limitaciones de velocidad y enriquecimiento previo.
• Arquitecturas híbridas: Combine la API de introducción para eventos y conectores para una reconciliación masiva.
• Activación de agente: Los eventos asignados en DMO en tiempo real pueden desencadenar flujos de trabajo Agentforce y modelos Einstein para la toma de decisiones automatizada.

Ejemplo

Una cadena minorista transmite eventos de compra de punto de venta (POS) en Data 360 en tiempo real para potenciar la implicación inmediata del cliente. Cada establecimiento ejecuta un componente de servidor ligero que recopila transacciones, las enriquece con metadatos de ubicación y dispositivo y publica de forma segura eventos JSON utilizando JWT Bearer OAuth con claves de idempotencia para evitar duplicados. Un administrador define la estructura del evento cargando un esquema de OAS para el punto de venta y configurando el conector de API de introducción. Los eventos entrantes se introducen en el DLO pos_sale, se asignan al DMO de ventas y se agregan al gráfico en tiempo real. Como resultado, las compras de alto valor se detectan al instante, desencadenando flujos de trabajo VIP en Agentforce y actualizando la segmentación de clientes para dirigir la personalización en tiempo real.

Contexto

Este patrón permite la captura de datos de interacción de usuario granulares de gran volumen (como vistas de página, clics de botón, impresiones de productos y reproducciones de vídeo) desde sitios web y aplicaciones móviles en tiempo real. Es fundamental para entregar personalización en el momento, donde cada interacción digital puede influir de forma dinámica en la experiencia del usuario e impulsar la implicación.

Problema

¿Cómo puede una empresa capturar y procesar una transmisión continua de eventos de comportamiento desde propiedades digitales, que abarcan millones de interacciones de usuario por minuto, y hacer que esos datos estén disponibles de inmediato en Data 360 para potenciar la segmentación, personalización y activación en tiempo real?

Fuerzas

Este caso de uso presenta varios retos de diseño que requieren una arquitectura de introducción de baja latencia creada específicamente:

• Rendimiento extremo: Los sitios web o aplicaciones móviles de alto tráfico pueden emitir millones de eventos por minuto. La capa de admisión debe ampliarse horizontalmente para gestionar este volumen sin pérdida de evento o contrapresión, garantizando una latencia coherente bajo cargas máximas.
• Instrumentación del lado del cliente: A diferencia de las integraciones dirigidas por servidor, este patrón depende de los SDK del lado del cliente. Una baliza de JavaScript (Salesforce Interactions SDK) debe estar integrada en cada página o un SDK nativo integrado en aplicaciones móviles. Esto requiere una implementación de cliente sólida, versiones y regulación de esquemas de eventos.
• Procesamiento de eventos de baja latencia: Las acciones de usuario, como “agregar al carrito” o “reproducción de vídeo”, deben alcanzar Data 360 en cuestión de segundos, activando la activación en tiempo real y respuestas contextuales (por ejemplo, ofertas dirigidas, recomendaciones personalizadas).
• Armonización y Resolución de Identidad: Los eventos capturados a menudo incluyen identificadores anónimos (cookies, Id. de dispositivo, tokens de sesión). Para potenciar casos de uso Customer 360, estos deben asignarse a perfiles conocidos a través de la resolución de identidad de Data 360 y armonizarse con el modelo de datos Customer 360.

Solución

El enfoque recomendado es utilizar el Conector de personalización de Salesforce Marketing Cloud, una canalización de transmisión nativa completamente gestionada diseñada para la introducción de comportamiento de alto rendimiento.

Boceto

Este diagrama ilustra la secuencia de pasos para introducir los datos desde canales móviles y web en Data 360

En este escenario:

• Implemente el SDK en canales web o móviles (captura de interacción de usuario).
• Configure SDK con Id. de arrendatario, entorno y controles de consentimiento.
• Transmita eventos JSON capturados (metadatos + atributos) al extremo de transmisión de Marketing Cloud.
• En Configuración de Data 360, cree y configure el Conector de personalización para el arrendatario.
• Introduzca eventos en un DLO y asigne el DLO → DMO dentro de Data 360.
• Active el DMO en el gráfico en tiempo real para una activación inmediata.
• Supervise la latencia, la conformidad de esquemas, los indicadores de consentimiento, el rendimiento, los índices de error.
• Implemente en producción y supervise continuamente.

Resultados

Una transmisión continua y de baja latencia de eventos de comportamiento fluye desde canales digitales a Data 360. En cuestión de segundos, cada acción de usuario queda disponible para segmentación en tiempo real, modelado predictivo o personalización desencadenada, permitiendo experiencias de cliente verdaderamente adaptativas.

Mecanismos de introducción

El mecanismo de introducción depende del conector y la estrategia de programación definida en Data 360.

Gestión y recuperación de errores

• Tolerancia a fallos en capas: Implemente mecanismos de validación y reintento de múltiples niveles: los SDK de cliente gestionan fallos transitorios con retroceso exponencial, mientras que la capa de introducción utiliza colas duraderas y oportunidades en curso reproducibles para evitar la pérdida de datos.
• Esquema y gobernanza de datos: Verifique y valide esquemas de eventos de forma continua; los eventos no válidos o en evolución se enrutan a una cola de rechazo de esquema o letra muerta para un triaje y reproducción seguros.
• Impotencia y deduplicación: Utilice identificadores de eventos estables y altere la semántica para garantizar el procesamiento exacto una vez incluso durante reintentos o repeticiones.
• Automatización de supervisión y recuperación: La supervisión continua del rendimiento, la latencia y los índices de error desencadena flujos de trabajo de recuperación automatizados, garantizando una baja latencia, una entrega fiable y resultados de personalización en tiempo real coherentes.

Consideraciones de diseño idempotentes

• Cada evento debe llevar una clave de idempotencia o un Id. de mensaje exclusivos de modo que los envíos duplicados se puedan deduplicar aguas abajo.
• Utilice claves comerciales (por ejemplo, sessionID + eventTimestamp + userID) cuando sea apropiado para identificar duplicados.
• Defina un plazo de deduplicación (por ejemplo, 24 horas) durante el cual se ignoran o se filtran los eventos duplicados.
• Utilice estrategias de alteración cuando corresponda (por ejemplo, actualizar contadores o indicadores en vez de insertar duplicados).

Consideraciones de seguridad

La seguridad es integral en todas las oportunidades en curso de introducción, desde la autenticación hasta el cifrado y el control de acceso.

• Cifrado de transporte: TLS 1.2+ para todas las conexiones de servicio de transmisión de SDK →.
• Cifrado de datos en periodo de inactividad en Data 360 y transmisión de marketing.
• El SDK respeta los indicadores de consentimiento y suprime el seguimiento si se deniega el consentimiento.
• Autenticación del tráfico de SDK: asegúrese de que solo los arrendatarios/clientes aprobados pueden transmitir eventos.
• Metadatos: cada evento debe incluir Id. de origen, marca de tiempo, versión de esquema, Id. de sesión, clave de idempotencia.
• Acceso con menos privilegios: Extremos y conectores de SDK limitados al ámbito de introducción de eventos; rotar credenciales regularmente.
• Clasificación de datos: Anotar PII en cargas de eventos, aplicar políticas inmediatamente después de la introducción

Barras laterales

Oportunidad

• La puntualidad depende de la actividad del usuario final y la configuración de transmisión de eventos.
• Los eventos capturados a través del SDK de interacciones de Salesforce y entregados a través de la transmisión de personalización de Marketing Cloud normalmente alcanzan una latencia de subsegundo a ~2 segundos antes de estar disponibles en el gráfico en tiempo real de Data 360.
• Esto permite la segmentación casi instantánea, la personalización y la activación en sesiones de usuario activas.

Volúmenes de datos

Los eventos de comportamiento individuales (por ejemplo, hacer clic, ver, agregar al carrito) son ligeros, generalmente de 1 a 5 KB por carga. Para propiedades digitales a gran escala, espere de miles a millones de eventos por minuto. Para garantizar el rendimiento y la resiliencia:

• Utilice los mecanismos de lote y reintento integrados del SDK para páginas de alto tráfico.
• Cargue la gestión de ráfagas en la capa intermedia de transmisión de Marketing Cloud.
• Supervise el rendimiento de introducción y los índices de error utilizando el panel de mediciones del conector.

Gestión de estado

Cada evento incluye metadatos para el control de estado y versión:

• Versión de esquema: Integre la versión del esquema en cada caso; versione el Conector de personalización cuando actualice el esquema.
• Gestión de reproducción: Los eventos que fallan debido a problemas de red transitorios se reintentan automáticamente por el SDK con retroceso exponencial.
• Claves de impotencia: Los identificadores exclusivos (sessionId + eventType + timestamp) garantizan que los eventos reproducidos no creen duplicados en Data 360.
• Gestión de compensación: Data 360 realiza un seguimiento de las confirmaciones correctas; cualquier evento no procesado se vuelve a poner en cola por el conector hasta que se introduzca correctamente.

Escenarios de integración complejos

Este patrón se integra perfectamente en arquitecturas empresariales avanzadas:

• Capa de enriquecimiento de borde: Agregue middleware (por ejemplo, proxy inverso o función sin servidor) para inyectar contexto adicional (como geo, tipo de dispositivo o metadatos de campaña) antes de que los eventos lleguen a Marketing Cloud.
• Híbrido (transmisión + lote): Utilice el conector de Marketing Cloud para transmisiones en tiempo real y combínelo con trabajos de ETL por lotes (por ejemplo, datos de pedidos) para la reconciliación descendente.
• Activación de agente: Los eventos asignados a DMO en tiempo real pueden desencadenar Personalización de Einstein, flujos de trabajo Agentforce o decisiones dirigidas por IA para adaptar la experiencia digital en el momento.
• Gobernanza de múltiples arrendatarios: Utilice indicadores de consentimiento y metadatos conscientes del arrendatario para aplicar la privacidad y el cumplimiento en entornos de múltiples marcas o regiones.

Ejemplo

Una empresa de comercio electrónico global entrega recomendaciones de productos personalizadas y contenido dinámico a compradores mientras navegan activamente por www.retailx.com, una aplicación de una sola página basada en React. Utilizando el SDK de interacciones de Salesforce en el lado del cliente, el sitio captura vistas de página, clics de productos, acciones de carrito e interacciones de vídeo en tiempo real. Estos eventos fluyen por la transmisión de eventos de Personalización de Marketing Cloud y el conector Personalización en DLO de Data 360, donde se modelan en DMO y se incorporan en el gráfico en tiempo real. Esta arquitectura hace que las señales de comportamiento estén disponibles al instante para la segmentación, la personalización dirigida por Einstein y la activación Agentforce, lo que permite experiencias de cliente con capacidad de respuesta en sesión

Contexto

Para muchos procesos críticos para el negocio, mantener Data 360 perfectamente alineado con las actualizaciones más recientes en sistemas CRM principales es esencial. Los equipos de atención al cliente, ventas y marketing dependen de información actualizada para dirigir decisiones, desencadenar trayectorias y activar la automatización. Este patrón proporciona un mecanismo para sincronizar cambios en objetos clave de Salesforce CRM (como Contacto, Cuenta y Caso) en Data 360 con un retraso mínimo, sin la ineficiencia o latencia de los sondeos por lotes frecuentes.

Problema

¿Cómo puede Data 360 mantener un estado casi perfectamente sincronizado con objetos clave de Salesforce CRM, garantizando que los análisis descendentes, la segmentación y la activación dirigida por IA siempre funcionan con los datos más actuales disponibles?

Fuerzas

Este patrón introduce varias restricciones técnicas y consideraciones arquitectónicas:

• Arquitectura dirigida por eventos: La sincronización debe ser reactiva, dirigida por eventos de cambio en la organización de origen de CRM en vez de trabajos por lotes periódicos.
• Soporte de objetos selectivos: No todos los objetos estándar y personalizados de Salesforce admiten la transmisión en tiempo real. Los arquitectos deben hacer referencia a la lista de objetos admitidos durante el diseño para evitar brechas.
• Acceso y permisos: La activación de la transmisión requiere que el usuario de integración en la organización de origen tenga asignado el permiso del sistema “Activar permisos para transmisión de CRM”.
• Actualización de datos frente a Coste de procesamiento: Aunque la sincronización casi en tiempo real mejora la capacidad de respuesta, un rendimiento de eventos excesivo puede requerir un escalado horizontal y mecanismos de recuperación de errores sólidos.
• Integración de capa de seguridad y confianza: Todos los datos de eventos deben cumplir los marcos de trabajo Trust and Security de Salesforce, cifrados en tránsito, validados para el cumplimiento de esquemas y procesados dentro del límite Trust de la organización.

Solución

El enfoque recomendado es utilizar el Conector de Salesforce CRM con la transmisión (Captura de datos de cambios) activada. Al crear una transmisión de datos para un objeto de CRM compatible (por ejemplo, Contacto), los administradores pueden alternar la opción “Activar transmisión”. De forma interna, la plataforma de Captura de datos de cambios (CDC) de Salesforce publica un mensaje ChangeEvent cada vez que se crea, se actualiza, se elimina o se cancela la eliminación de un registro en la organización de CRM de origen. El conector de CRM de Data 360 se suscribe a estos eventos de CDC y aplica los cambios correspondientes al objeto de lago de datos (DLO) asignado dentro de Data 360 casi en tiempo real. Esto garantiza una sincronización continua entre CRM y Data 360 con una intervención manual mínima.

Boceto

Este diagrama ilustra la secuencia de pasos para introducir los datos desde CRM en Data 360 casi en tiempo real

En este escenario:

• El cambio se produce en Salesforce CRM (create/update/delete/undelete).
• Los CDC publican un ChangeEvent en el Bus de eventos de Salesforce interno.
• El conector de CRM de Data 360 se suscribe al bus de eventos utilizando un cursor de reproducción duradero.
• La carga de evento se valida para esquema, permisos e integridad de datos.
• Data 360 escribe el evento validado en el Objeto de lago de datos (DLO) asignado.
• Si se activa, los objetos de modelo de datos asignados se actualizan casi en tiempo real, potenciando la segmentación y la activación.

Resultados

Data 360 mantiene un espejo sincronizado continuamente de datos clave de CRM. Esto permite:

• Desencadenadores en tiempo real (p. ej., Inicios de trayectoria cuando se crea un caso).
• Segmentación actualizada (por ejemplo, mover clientes al segmento “Oro” tras el cambio de estado de Cuenta).
• Análisis y personalización más precisos basados en contexto de CRM en vivo.

Mecanismos de introducción

El mecanismo de introducción para este patrón se gestiona de forma nativa a través del conector de Salesforce CRM con Captura de datos de cambios (CDC) activada. Data 360 actúa como un suscriptor de la transmisión de eventos de CDC, garantizando una sincronización fiable y de baja latencia entre la organización de CRM de origen y Data 360.

Gestión y recuperación de errores

• Recuperación automática de fallos: El conector de CRM reintenta automáticamente errores transitorios de red o plataforma utilizando retroceso exponencial y enruta fallos persistentes a la cola de letras muertas (DLQ) para su reproducción.
• Resistencia a esquemas y autenticación: Los desajustes de esquemas se ponen en cuarentena en la cola de rechazo de esquemas para su revisión por el administrador, mientras que los errores de autenticación o permisos desencadenan reintentos controlados y alertas a través de Supervisión de Data 360.
• Continuidad de eventos garantizada: Los ReplayID duraderos garantizan que no haya pérdida de eventos durante el tiempo de inactividad del conector; los eventos perdidos se rehidratan a través de plazos de reproducción o trabajos de resincronización por lotes.
• Integridad y ordenación de datos: La idempotencia integrada (RecordID + SequenceNumber) evita duplicados, y ChangeEventHeader.sequenceNumber conserva la ordenación correcta de eventos para cada registro de CRM.

Consideraciones de diseño idempotentes

• Event Uniqueness: Cada evento de CDC lleva un ReplayID y ChangeEventHeader.entityName para la deduplicación determinista.
• Estrategia de inserción: Implemente la lógica UPSERT basada en el Id. de registro para garantizar que los eventos repetidos no creen duplicados.
• Gestión de reproducción: Utilice el cursor de reproducción del conector para reanudar desde la última compensación confirmada en caso de fallos transitorios.
• Evolución de esquema: MMantenga una versión de esquema en metadatos de eventos y actualice asignaciones de DLO cuando cambie el esquema de CRM.

Consideraciones de seguridad

La seguridad es integral en todas las oportunidades en curso de introducción, desde la autenticación hasta el cifrado y el control de acceso.

• Encryption and Trust: Todos los eventos se transmiten utilizando TLS 1.2+ y se almacenan cifrados en tiempo de inactividad en Data 360.
• Control de acceso: Solo los conectores autenticados con permisos de integración apropiados pueden suscribirse a canales de CDC.
• Validación de esquema: Cada carga de evento se valida con el esquema de DLO antes de la introducción.
• Propagación de consentimiento: Los metadatos de consentimiento y clasificación de datos fluyen hacia abajo con cada evento para preservar la privacidad y el cumplimiento (RGPD, CCPA).
• Gobernanza operativa: Los eventos se registran, auditan y supervisan en busca de reproducción, rechazo de esquemas y anomalías de rendimiento a través de Data 360 Trust Layer.

Barras laterales

Oportunidad

• Los eventos de CDC se procesan casi en tiempo real, normalmente en cuestión de segundos desde el cambio en CRM.
• La latencia puede variar basándose en el volumen de eventos y el rendimiento del conector, pero Data 360 garantiza la disponibilidad de subminutos para objetos compatibles.

Volúmenes de datos

• Cada carga de evento es ligera (~1-5 KB).
• Para objetos de alto índice de cambio como Caso o Contacto, asegúrese de que los límites de rendimiento se alinean con las asignaciones de eventos de Salesforce CDC.

Gestión de estado

Cada evento incluye metadatos para el control de estado y versión:

• Id. de reproducción: Se utiliza para la recuperación de eventos secuencial.
• Versión de esquema: Mantenga metadatos de versión para gestionar cambios de contrato.
• Claves de impotencia: Deduplique repeticiones entre reintentos.
• Comprobar compensación: Data 360 mantiene el estado de confirmación después de cada lote de eventos correcto.

Escenarios de integración complejos

Este patrón se integra perfectamente en arquitecturas empresariales avanzadas:

• Híbrido (transmisión + lote): Utilice CDC para actualizaciones delta y trabajos masivos para actualizaciones completas.
• Transmisión entre organizaciones: Múltiples organizaciones de origen pueden transmitir en el mismo arrendatario de Data 360, unificado a través de asignaciones de DMO.
• Activación de agente: Las actualizaciones de objetos en tiempo real desencadenan automatizaciones Einstein o Agentforce.
• Enrutamiento de eventos: El middleware (por ejemplo, MuleSoft o Event Relay) puede enriquecer o enrutar mensajes de CDC antes de la introducción.

Ejemplo

Un banco global desea asegurarse de que los cambios de datos de clientes en Salesforce Sales Cloud se reflejan instantáneamente en Data 360.Cuando se actualiza la dirección de un Contacto en Sales Cloud, el mecanismo Cambiar Captura de datos publica un ContactChangeEvent.El Conector de CRM de Data 360 consume este evento, aplica la actualización al DLO de cliente y actualiza automáticamente todos los perfiles Customer 360 asociados. Esto desencadena una Einstein Next Best Action para verificar la nueva dirección, completando el bucle de comentarios en cuestión de segundos desde el cambio de CRM original.

Contexto

Las empresas digitales modernas se basan en plataformas de transmisión de eventos en tiempo real como Amazon Kinesis Data Streams y Amazon MSK (Transmisión gestionada para Apache Kafka) para capturar flujos de datos continuos desde aplicaciones distribuidas, dispositivos IoT y sistemas transaccionales. Data 360 permite la introducción directa desde estas plataformas a través de conectores nativos de primera parte, eliminando la necesidad de soluciones personalizadas basadas en ETL o middleware. Este patrón está diseñado para el ingreso de datos de alto rendimiento y baja latencia, potenciando perspectivas casi en tiempo real, personalización y activación dirigida por IA.

Problema

¿Cómo puede una empresa conectar Data 360 de forma segura y eficiente con temas de AWS Kinesis o AWS MSK Kafka para introducir continuamente datos de eventos y perfiles estructurados, garantizando el cumplimiento de esquemas, la capacidad de ampliación y la gobernanza?

Fuerzas

Este patrón presenta múltiples consideraciones arquitectónicas y operativas:

• Disponibilidad de conector nativo: Salesforce proporciona conectores nativos disponibles de forma general para Amazon Kinesis y Amazon MSK. Estos conectores ofrecen asistencia de primera parte y eliminan la necesidad de oportunidades en curso basadas en API personalizadas.
• Autenticación y seguridad: Cada conector requiere autenticación a nivel de AWS.
• Para Kinesis, utiliza Clave de acceso de AWS y Clave secreta, regidas por políticas de IAM.
• Para MSK, la autenticación se puede configurar a través de Clave de acceso/Secreto u OpenID Connect (OIDC).
• Definición de esquema: Data 360 requiere un esquema para interpretar la carga de transmisión. Para Kinesis, el archivo de esquema se carga durante la configuración de la conexión, definiendo la estructura de eventos y las asignaciones de campos.
• Origen de configuración:
• El conector de Kinesis se suscribe a un nombre de transmisión de Kinesis específico.
• El conector MSK se suscribe a un tema de Kafka dentro del clúster de MSK.
• Acceso de red: Para entornos seguros, los conectores se pueden configurar con el enrutamiento PrivateLink o VPC, garantizando que ningún dato atraviese la Internet pública.
• Gobernanza operativa: El rendimiento de transmisión, la validación de esquemas y los eventos de autenticación se supervisan dentro de Data 360 Trust Layer, garantizando el cumplimiento y la trazabilidad.

Solución

La solución aprovecha los conectores nativos Amazon Kinesis o Amazon MSK en Data 360.

Boceto

Este diagrama ilustra la secuencia de pasos para introducir los datos desde plataformas de eventos como Kafka y Kinesis en Data 360 casi en tiempo real

En este escenario:

• Las aplicaciones o dispositivos publican eventos en Transmisión de Kinesis o Tema de MSK.
• El conector de Data 360 se autentica utilizando credenciales de AWS o token de OIDC.
• El conector consulta o se suscribe continuamente a la transmisión.
• Los eventos se organizan, se validan para esquemas y políticas, luego se confirman en Objeto de lago de datos (DLO).
• Si se asignan, los objetos del modelo de datos (DMO) se actualizan casi en tiempo real para su activación.
• Capa de supervisión realiza un seguimiento de mediciones, rechazos de esquemas y latencia.

Resultados

La introducción continua y de baja latencia de datos estructurados directamente desde AWS Kinesis o MSK en Data 360. Los datos están disponibles de inmediato para:

• Resolución de identidad
• Segmentación en tiempo real
• Activación de IA de Einstein
• Desencadenadores dirigidos por Agentforce Elimina la dependencia de ETL por lotes, permitiendo arquitecturas basadas en transmisiones alineadas con diseños dirigidos por eventos empresariales.

Mecanismos de introducción

Gestión y recuperación de errores

• Reintentos automáticos: Los conectores reintentan errores transitorios de red o plataforma con retroceso exponencial.
• Rechazos de esquemas: Las cargas no válidas se dirigen a la cola de rechazo de esquemas para su revisión por el administrador.
• Reproducción de DLQ: Los fallos persistentes se capturan en colas de letra muerta para su reprocesamiento.
• Control de impotencia: Las claves de eventos o los números de secuencia garantizan la desduplicación y la introducción ordenada.
• Supervisión de la integración: Todos los fallos, reintentos y mediciones de rendimiento afloran en paneles de Supervisión de Data 360.

Consideraciones de diseño idempotentes

• Exclusividad y seguimiento de eventos: Cada evento tiene asignada una clave exclusiva determinista (por ejemplo, PartitionKey + SequenceNumber para Kinesis o Topic + Partition + Offset para MSK) para garantizar la ingesta exacta una vez.
• Punto de control de conector: Los conectores de Data 360 mantienen la última compensación procesada o número de secuencia para reanudar la introducción de forma segura después de fallos o reinicios.
• Deduplicación y lógica de alteración: Durante las confirmaciones de DLO, se detectan y se omiten eventos duplicados; los registros válidos se alteran utilizando la clave exclusiva para mantener la coherencia.
• Control de reproducción y recuperación: Los eventos fallidos o retrasados se reproducen desde compensaciones almacenadas a través de colas de letra muerta y reproducción, garantizando una recuperación fiable sin duplicación.

Consideraciones de seguridad

La seguridad es integral en todas las oportunidades en curso de introducción, desde la autenticación hasta el cifrado y el control de acceso.

• Autenticación: Proteja el intercambio de credenciales utilizando políticas de AWS IAM u OIDC.
• Cifrado: Datos cifrados en tránsito (TLS 1,2+) y en reposo (AES-256) dentro de Data 360.
• Control de acceso: Funciones con menos privilegios aplicadas; conectores con ámbito a transmisiones/temas específicos.
• Gobernanza: Metadatos de linaje y clasificación aplicados a cada registro para una trazabilidad completa.
• Seguridad de red: Implemente opcionalmente dentro de subredes privadas utilizando AWS PrivateLink.

Barras laterales

Oportunidad

• Procesamiento casi en tiempo real: Los conectores de CDC y transmisión procesan eventos en cuestión de segundos desde los cambios de origen, normalmente garantizando la actualización de datos subminutos.
• Latencia determinista: El retardo de extremo a extremo depende del rendimiento de origen, los lotes de eventos y las condiciones de red, pero Data 360 garantiza una latencia dirigida por SLA predecible para objetos compatibles.
• Escala elástica: Las oportunidades en curso de introducción se amplían automáticamente bajo un alto volumen de eventos, preservando la puntualidad incluso durante ráfagas de datos de pico.
• Visibilidad operativa: Los paneles de supervisión exponen el retardo de eventos, confirman marcas de tiempo y reproducen el estado para garantizar la latencia y solucionar problemas.

Volúmenes de datos

• Cargas ligeras: Los eventos de transmisión o CDC individuales son compactos (tamaño habitual de 1 a 5 KB), optimizados para actualizaciones de alta frecuencia.
• Objetos de alto cambio: Para entidades volátiles (por ejemplo, Caso, Contacto, Pedido), los arquitectos deben garantizar que las asignaciones de CDC y el rendimiento de eventos se alinean con los índices de actualización esperados.
• Transmisiones paralelas: Data 360 admite la introducción de múltiples transmisiones para el escalado horizontal entre grandes volúmenes de objetos u múltiples organizaciones de origen.
• Gestión de contrapresión: Los mecanismos de estrangulación integrados mantienen la estabilidad de introducción bajo carga sin eventos de caída.

Gestión de estado

Cada evento incluye metadatos para el control de estado y versión:

• Reproducción y Seguimiento de compensación: Cada evento lleva Id. de reproducción y metadatos de secuencia, lo que permite la entrega ordenada y la recuperación basada en puntos de control.
• Versión de esquema: Las etiquetas de versión en encabezados de eventos garantizan un procesamiento compatible con versiones anteriores cuando evolucionan los esquemas de origen.
• Claves de impotencia: Cada evento incluye una transacción exclusiva o clave de confirmación, lo que permite a Data 360 deduplicar repeticiones y reintentos de forma segura.
• Comprobación atómica: Las oportunidades en curso de introducción solo marcan las compensaciones como completas una vez que las confirmaciones descendentes con los DLO tienen éxito, garantizando la coherencia.

Escenarios de integración complejos

Este patrón se integra perfectamente en arquitecturas empresariales avanzadas:

• Ingestión híbrida: Combine CDC para deltas incrementales con transmisiones de datos masivas para actualizaciones completas, manteniendo la actualización y la exhaustividad.
• Transmisión entre organizaciones: Múltiples organizaciones de CRM o ERP pueden publicar en el mismo arrendatario de Data 360, unificado a través de asignación de DMO y alineación de ontología.
• Enriquecimiento de eventos: El middleware (por ejemplo, MuleSoft, Event Relay) puede enriquecer, filtrar o enrutar datos de transmisión antes de que alcancen Data 360.
• Activación de IA y agente: Las actualizaciones en tiempo real desencadenan la automatización descendente, como predicciones Einstein o respuestas Agentforce, en cuestión de segundos desde el evento de origen.

Ejemplo

Una empresa minorista global utiliza AWS Kinesis para transmitir datos de punto de ventas e interacción web.El conector Kinesis de Data 360 se autentica a través de credenciales IAM e introduce eventos continuamente en un DLO de transacciones.Cada registro se valida con esquemas, se enriquece con metadatos y se propaga inmediatamente al DMO de clientes.En cuestión de segundos, los modelos de IA de Einstein actualizan segmentos de clientes y Agentforce desencadena recomendaciones de la siguiente mejor oferta en tiempo real, logrando un bucle de personalización completamente dirigido por eventos.

Cero copia es más que un método de integración: es un cambio fundamental en el modo en que se mueven los datos de la empresa, o mejor dicho, no se mueven. Tradicionalmente, la integración de datos requería copiar grandes volúmenes de registros a través de oportunidades en curso de ETL, creando almacenes de datos redundantes, retrasos de sincronización y retos de gobernanza. La copia cero elimina todo eso. En este modelo, Data 360 se conecta directamente a plataformas de datos externas como Snowflake y Databricks, leyendo y activando datos de forma segura, sin moverlos o duplicarlos nunca. El resultado es un puente sin problemas entre su lago de datos de empresa y el ecosistema de Salesforce, proporcionando acceso instantáneo, un menor gasto operativo y una gobernanza de datos más sólida.

Las funciones de copia cero entrantes permiten a Data 360 consultar y armonizar datos externos en el origen, como perfiles de clientes, transacciones o datos de productos, almacenados en Snowflake o Databricks. En vez de introducir archivos, Data 360 establece una conexión segura y consciente de los metadatos que aprovecha las definiciones de esquemas y las políticas de seguridad existentes en el almacén externo.

• Federación directa: Data 360 lee datos existentes a través de consultas seguras y optimizadas sin replicación.
• Gobernanza unificada: Los datos permanecen bajo el marco de seguridad, control de acceso y cumplimiento del sistema de origen.
• Eficiencia operativa: Elimina la duplicación de gastos generales y almacenamiento de ETL, reduciendo el coste y la complejidad.
• Preparación en tiempo real: Activa Armonización on-demand: en el momento en que se actualizan los datos en Snowflake, están disponibles inmediatamente para su activación en Data 360.

Contexto

Las empresas modernas dirigidas por datos gestionan petabytes de datos de clientes, transacciones y telemetría en plataformas de lago de datos a escala de nube como Snowflake y Databricks. Estos entornos sirven como la única fuente de verdad para análisis, IA y cumplimiento. Data 360 presenta Zero CopyData Federation, permitiendo a Data 360 consultar y utilizar directamente conjuntos de datos externos establecidos, sin copiar, transformar o almacenar datos redundantes. Este patrón permite a las organizaciones ampliar el tejido Customer 360 a su infraestructura de almacén de datos o lago existente, logrando la unificación y activación en tiempo real con cero duplicaciones, cero latencia y cero compromisos en la regulación.

Problema

¿Cómo pueden las empresas aprovechar conjuntos de datos enriquecidos ya depurados en Snowflake, Databricks o formatos de lago abierto como Apache Iceberg, para segmentación, resolución de identidad y activación en Data 360, sin el coste, la latencia y el gasto general de regulación de las oportunidades en curso de ETL o el movimiento de datos físico?

Fuerzas

Este patrón presenta múltiples consideraciones de arquitectura, seguridad y rendimiento:

Red y seguridad

• Data 360 debe establecer una conexión privada y segura con el almacén externo o el lago.
• Normalmente se configura utilizando Salesforce Private Connect o PrivateLink/VPC Peering, garantizando que el tráfico nunca salga de la red controlada del cliente.
• Los sistemas externos deben incluir en la lista de admisión direcciones IP de Data 360 y aplicar el cifrado TLS 1.2+.

Autenticación y control de acceso

• Admite autenticación de pares de claves, OAuth 2.0 o delegación Trust basada en proveedor de identidad (IdP) (Data 360 actuando como un cliente de confianza)
• El control de acceso basado en funciones (RBAC) en el sistema externo aplica el acceso de menor privilegio para la ejecución de consultas.

Dependencia de rendimiento y computación

• La federación de consultas empuja hacia abajo la ejecución de SQL en Snowflake o Databricks, aprovechando sus clústeres de computación.
• Rendimiento y escala de costes con carga de consulta externa: La latencia y el coste de segmentación están vinculados a la configuración de computación externa.

Estándares en evolución: Federación de archivos

• Un modelo de próxima generación, Federación de archivos, aprovecha formatos de tabla abiertos como Apache Iceberg o Delta Lake, permitiendo a Data 360 leer directamente desde el almacenamiento de objetos (por ejemplo, Amazon S3, Azure ADLS, Google Cloud Storage).
• Al omitir la capa de cálculo de origen, Federación de archivos reduce drásticamente la latencia y el coste para cargas de trabajo analíticas pesadas de lectura mientras mantiene la integridad del esquema.

Gobernanza y cumplimiento

• Los datos nunca abandonan la plataforma de origen: las políticas de cumplimiento, cifrado y retención permanecen aplicadas en origen.
• Todos los atributos de metadatos, linaje y consentimiento se propagan a Trust Layer de Data 360 para garantizar la trazabilidad de extremo a extremo.

Solución

El enfoque recomendado es utilizar conectores de copia cero nativos para Snowflake, Databricks o Federación de archivos dentro de Data 360.

Boceto

El siguiente diagrama ilustra cómo configurar una conexión de copia cero y crear DLO externos en Data 360.

En este escenario:

• El administrador configura una conexión Cero copia en Configuración de Data 360 (Snowflake, Databricks o Federación de archivos).
• Se establecen la autenticación segura y el enrutamiento de red (Conexión privada / OAuth / Par de claves).
• El administrador crea una transmisión de datos seleccionando el origen externo: explorando bases de datos en vivo, esquemas y tablas.
• En vez de copiar datos, Data 360 crea un DLO externo (Objeto de lago de datos): un puntero de metadatos que hace referencia a la tabla en vivo o el archivo Iceberg.
• Los DLO externos se asignan a entidades Customer 360 (por ejemplo, Cliente, Transacción, Producto).
• Data 360 consulta el origen durante la segmentación, activación o cálculo de perspectivas.
• Todo el acceso, el linaje de la consulta y los metadatos se auditan en Data 360 Trust Layer.

Resultados

• Los datos externos permanecen en Snowflake, Databricks o S3, sin ETL, sin duplicación ni almacenamiento adicional.
• Data 360 obtiene acceso en tiempo real y en tiempo de lectura a datos a escala empresarial para la resolución de identidad, perspectivas calculadas y activación.
• Las organizaciones mantienen el control completo bajo sus marcos de trabajo de gobernanza, cifrado y cumplimiento existentes.
• Este patrón permite una verdadera arquitectura de copia cero, combinando el rendimiento del acceso local con la regulación del almacenamiento federado.

Mecanismos de llamada

El mecanismo de llamada depende de la solución elegida para implementar este patrón.

Gestión y recuperación de errores

• Reintento automático y retroceso de consulta: La conectividad transitoria o los tiempos de espera de consultas se reintentan automáticamente utilizando retroceso exponencial.
• Aislamiento de desajuste de esquema: Los cambios en el esquema de origen (por ejemplo, nuevas columnas) se registran en la cola de rechazo de esquemas; los administradores pueden volver a asignar o actualizar metadatos de esquemas.
• Conmutación por error de autenticación: Si las credenciales caducan, Data 360 reintenta la conexión utilizando tokens de actualización almacenados o políticas de rotación de claves.
• Computar detección de disponibilidad: Si Snowflake o el clúster de Databricks están en pausa, Data 360 suspende trabajos de federación y reintenta cuando se reanuda el cálculo.
• Supervisión de la integración: Todos los metadatos de estado de conexión, latencia de consulta y linaje visibles en paneles de Supervisión de Data 360.

Consideraciones de diseño idempotentes

• Determinismo de consulta: Las consultas federadas utilizan semántica de instantánea coherente para garantizar lecturas estables y repetibles durante la segmentación o activación.
• Versión de DLO externo: Cada consulta federada incluye metadatos de esquemas y marcas de tiempo para el seguimiento del linaje.
• Acceso sin compensación: Dado que Cero copia es de solo lectura, no se basa en compensaciones de eventos: la coherencia se aplica a través de las garantías ACID del sistema externo (Snowflake/Delta Lake).
• Gestión de deriva de esquema: Mantenga asignaciones de esquemas versionadas en Data 360; actualice metadatos de DLO externo en evolución de origen.

Consideraciones de seguridad

La seguridad es integral en todo el modelo de federación, lo que garantiza que no haya compromisos en Trust o cumplimiento.

• Cifrado: Todos los intercambios de datos utilizan TLS 1.2+; los almacenes externos se cifran en periodos de inactividad utilizando AES-256.
• Control de acceso: Se accede a las tablas externas a través de funciones de menor privilegio con permisos de solo lectura.
• Aislamiento de red: Las rutas de Conexión privada o VPC evitan cualquier exposición a extremos públicos.
• Flujo de datos gobernado: Los metadatos de linaje, consentimiento y clasificación fluyen a Data 360 Trust Layer para la aplicación de políticas.
• Auditabilidad: Cada consulta federada y evento de acceso a esquemas se registra para la trazabilidad de cumplimiento (RGPD, CCPA, HIPAA).

Barras laterales

Oportunidad

• Las consultas se ejecutan en vivo en el almacén o almacenamiento externo, garantizando la visibilidad en tiempo real del estado de datos más reciente.
• Las ejecuciones de segmentación o activación reflejan cambios al segundo en Snowflake, Databricks o tablas de Iceberg respaldadas por S3.
• La latencia de la consulta depende del nivel de rendimiento del sistema de origen, normalmente de segundos a decenas de segundos por consulta.
• Ideal para cargas de trabajo analíticas y de IA que requieren acceso a datos “frescos, no copiados”.

Volúmenes de datos

• Admite conjuntos de datos a escala de petabytes almacenados de forma nativa en Snowflake o Databricks sin replicación.
• Data 360 solo recupera resultados, no conjuntos de datos sin procesar, minimizando los costes de computación y red.
• Federación de archivos optimiza grandes exploraciones analíticas a través de la poda de particiones y la distribución de columnas.
• Se amplía linealmente con la capacidad de cálculo del almacén y la capa de orquestación de consultas federadas de Data 360.

Gestión de estado

• Los DLO externos mantienen la conexión, el esquema y los metadatos de versión en Data 360.
• La evolución de esquemas se gestiona automáticamente a través de ciclos de actualización de metadatos.
• El linaje de consulta incluye marcas de tiempo, identidad de usuario y mediciones de ejecución para la trazabilidad.
• No se mantiene ninguna introducción o compensación de estado: la coherencia se hereda de las garantías ACID de la fuente externa.

Escenarios de integración complejos

• Modo híbrido: Combine Cero copia (para federación en vivo) con introducción (para conjuntos de datos históricos).
• Acceso entre almacenes: Data 360 puede federarse desde múltiples arrendatarios de Snowflake o Databricks en una organización.
• Interoperabilidad IA/BI: Los sistemas externos (por ejemplo, SageMaker, Tableau, Power BI) pueden consultar los perfiles enriquecidos de Data 360 a través de Cero copia inversa.
• Extensión Federación de archivos: Las empresas que adoptan formatos de lago abierto (Iceberg/Delta) pueden unificar datos estructurados y no estructurados bajo un modelo federado.

Ejemplo

Una empresa financiera global almacena todos los datos de transacciones e interacciones en Snowflake, mientras mantiene atributos de clientes y eventos de marketing en Data 360. Utilizando Federación de datos de copia cero, Data 360 se conecta de forma segura a Snowflake a través de Conexión privada. Cuando se ejecuta un trabajo de segmentación, por ejemplo, “Clientes con un gasto >10.000 $ en los últimos 30 días, Data 360 envía la consulta a Snowflake, recupera resultados agregados y activa esos perfiles al instante en Journey Builder. No se necesita replicación o ETL. Este ejemplo utiliza inteligencia federada en tiempo real que está unificada en el ecosistema de datos de la empresa.

La copia cero saliente amplía el mismo principio a la inversa. En vez de exportar o copiar conjuntos de datos desde Data 360, los sistemas externos como Snowflake pueden consultar Data 360 directamente, tratándolo como una fuente federada de Inteligencia de clientes enriquecida.

• Federación inversa: Las plataformas de análisis externo o IA pueden acceder a los datos de perfil unificado de Data 360 sin extraerlos.
• Activación de datos en origen: Los equipos comerciales pueden aprovechar perspectivas donde ya residen los datos, ya sea para el modelado de IA, la creación de informes o la personalización de clientes.
• Interoperabilidad sin latencia: Sin exportaciones por lotes ni trabajos de sincronización; las perspectivas fluyen instantáneamente entre plataformas.
• Semántica coherente: Debido a que ambos sistemas comparten la misma ontología y asignaciones de esquemas, el contexto y el significado se mantienen entre ecosistemas. La copia cero redefine la función de Data 360 desde un depósito de datos a una capa de activación semántica. Permite a las organizaciones mantener los datos exactamente donde pertenecen (en almacenes gobernados de alto rendimiento) mientras desbloquean su valor completo dentro del límite Trust de Salesforce. Este patrón se alinea con la malla de datos moderna y las arquitecturas nativas de IA: los datos permanecen descentralizados, pero la inteligencia se unifica. Los arquitectos ahora pueden crear oportunidades en curso de activación que son más rápidas, más sencillas y más compatibles; no se requiere copia.

Contexto

Las empresas modernas operan cada vez más en ecosistemas de datos de múltiples plataformas, donde Salesforce Data 360 potencia la activación y los perfiles de clientes unificados, mientras que los almacenes de datos empresariales como Snowflake o Databricks sirven como columnas vertebrales analíticas para la ciencia de datos, el aprendizaje automático y las cargas de trabajo de BI. La función Colaboración saliente de copia cero de Salesforce Data 360 acorta estos entornos a la perfección, permitiendo el acceso gobernado, seguro y en tiempo real a datos armonizados de Data 360 directamente dentro de Snowflake o Databricks, sin replicación o ETL. Esto permite a los analistas y científicos de datos consultar, visualizar y modelar en los mismos datos en vivo de confianza que potencian el marketing, las ventas y la activación de servicios.

Problema

¿Cómo puede una empresa exponer de forma segura y eficiente los perfiles de clientes unificados y las mediciones calculadas de Data 360 (por ejemplo, Valor de vida útil, Riesgo de abandono) a sistemas analíticos externos, sin copiar datos, interrumpir la regulación o introducir latencia a través de oportunidades en curso ETL inversas tradicionales?

Fuerzas

Este patrón presenta múltiples consideraciones arquitectónicas, de gobernanza y operativas:

• Seguridad gubernamental: El acceso a los datos de Data 360 debe ser controlado, granular y auditable. La colaboración de copia cero utiliza acceso explícito a nivel de objeto, garantizando que solo los Objetos de modelo de datos (DMO) y los Objetos de perspectiva calculada (CIO) aprobados estén disponibles para consumidores designados.
• Selección de objeto explícita: Los administradores depuran los datos que se pueden compartir a través de un Uso compartido de datos, seleccionando explícitamente qué objetos exponer. Esto mantiene la regulación y minimiza la exposición al riesgo.
• Configuración Bi-Lateral: Tanto Data 360 como el almacén externo requieren configuración. Data 360 define el Objetivo de colaboración de datos (Snowflake/Databricks), mientras que el sistema receptor debe aceptar e instanciar la colaboración.
• Modelo de federación de consultas: Una vez aceptada, la plataforma externa consulta datos de Data 360 en vivo gobernados a través de vistas federadas, eliminando trabajos de extracción o ciclos de actualización manuales.
• Evolución de estándares abiertos: Los enfoques emergentes como Federación de archivos aprovechan formatos de tabla abiertos (por ejemplo, Apache Iceberg) para activar el acceso de solo lectura en la capa de almacenamiento, mejorando la escalabilidad, el rendimiento y la interoperabilidad entre arquitecturas de múltiples nubes.

Solución

La solución aprovecha la colaboración de copia cero nativa de Salesforce Data 360 con plataformas de datos como Snowflake o Databricks.

Boceto

El siguiente diagrama ilustra una llamada desde Salesforce Data 360 a una plataforma de datos externa.

En este escenario:

• Administrador de Data 360 define una colaboración de datos incluyendo objetos Cliente unificado y Perspectiva calculada.
• Un Objetivo de colaboración de datos (cuenta de Snowflake o Databricks) se registra con credenciales seguras y políticas de gobernanza.
• Data 360 publica la colaboración; los administradores de Snowflake/Databricks la aceptan.
• Los datos compartidos aparecen como tablas de solo lectura seguras en el almacén.
• Analistas, herramientas de BI o oportunidades en curso de ML consultan los datos de clientes unificados en vivo sin copiar o sincronizar.
• Todo el acceso se audita en los registros de gestión de Data 360 Trust Layer y almacén.

Resultados

• Los almacenes externos obtienen acceso consultable en tiempo real a datos armonizados de Data 360.
• Elimina las oportunidades en curso de ETL inversas, reduciendo la carga operativa y la latencia.
• Activa entrenamiento de IA/ML, modelado predictivo y BI avanzado directamente en datos unificados.
• Mantiene cero duplicaciones, una gobernanza sólida y un control de acceso seguro por diseño.
• Completa el bucle bidireccional Cero copia, donde la federación entrante y la colaboración saliente coexisten bajo un único modelo de gobernanza.

Mecanismos de llamada

El mecanismo de llamada depende de la solución elegida para implementar este patrón.

Gestión y recuperación de errores

• Reintentos de conexión: Reintentos automatizados para fallos de conexión o autenticación transitorios entre Data 360 y el almacén.
• Validación de colaboración: Las configuraciones de colaboración no válidas o no autorizadas se ponen en cuarentena en una Cola de revisión de administrador.
• Supervisión de estado de sincronización: Data 360 aflora el estado de colaboración en vivo, la latencia de consultas y los registros de acceso a través de paneles de Supervisión.
• Revocación de acceso: Los administradores pueden revocar colaboraciones instantáneamente, desactivando el acceso en ambos extremos sin copias de datos residuales.
• Seguimiento de auditoría gobernado: Todos los cambios de configuración y acceso se registran para la verificación del cumplimiento.

Consideraciones de diseño idempotentes

• Identificación de colaboración coherente: Cada par Uso compartido de datos y Objetivo de uso compartido de datos tiene un identificador exclusivo, garantizando la regulación exacta y la trazabilidad de acceso.
• Vistas inmutables: Los objetos de datos compartidos son de solo lectura; los consumidores no pueden mutar el estado, garantizando resultados deterministas y cumplimiento.
• Ciclo de vida de colaboración atómica: La publicación de colaboración, la revocación y las actualizaciones son operaciones atómicas, ya sea completamente completadas o revertidas.
• Coherencia de reproducción: Cuando se actualizan los datos de Data 360, las consultas del lado del almacén siempre devuelven la última instantánea coherente, eliminando lecturas obsoletas.

Consideraciones de seguridad

La seguridad sustenta todos los aspectos del uso compartido de copia cero:

• Autenticación: Mutual Trust establecido utilizando OAuth 2.0, intercambio de claves privadas o federación de identidad (OIDC).
• Cifrado: Datos cifrados en tránsito (TLS 1,2+) y en reposo (AES-256).
• Control de acceso: Los permisos a nivel de objeto aplican el acceso con menos privilegios; gobernados por Data 360 Trust Layer.
• Seguridad de red: Los intercambios de datos se producen a través de vínculos de red privados como Salesforce Private Connect o las API de intercambio de datos seguras.
• Metadatos de gobernanza: Cada objeto compartido incluye atributos de linaje, clasificación y consentimiento para una trazabilidad completa y cumplimiento normativo.

Barras laterales

Oportunidad

• Disponibilidad en tiempo real: Los datos compartidos reflejan el estado más actual de Data 360 sin retrasos de replicación.
• Query Freshness: Los cambios en DMO o CIO se propagan instantáneamente a vistas de almacén compartidas.
• Elasticidad de rendimiento: La distribución de consultas se adapta de forma dinámica a recursos informáticos de almacén.
• Supervisión: Los paneles en vivo exponen mediciones de rendimiento de consulta y latencia compartidas para la seguridad operativa.

Volúmenes de datos

• Compartición ampliable: Admite el uso compartido de datos granulares a nivel de objeto o de dominio completo dependiendo de las necesidades analíticas.
• Rendimiento de consultas optimizado: Snowflake/Databricks almacenan en caché datos compartidos de forma inteligente para minimizar la latencia.
• Eficiencia de almacenamiento: La duplicación cero elimina costes de almacenamiento redundantes.
• Federación de archivos Opción: Para conjuntos de datos a escala de petabytes, la colaboración basada en Iceberg directa omite el cálculo y acelera el acceso.

Gestión de estado

• Evolución de esquema: Los esquemas controlados por versión garantizan la compatibilidad cuando evoluciona el modelo de Data 360.
• Seguimiento de estado de acceso: Estados de colaboración activos/inactivos mantenidos en Data 360 para la regulación del ciclo de vida.
• Sincronización de metadatos: Las actualizaciones en definiciones de objetos compartidos se reflejan automáticamente en catálogos de almacén descendentes.
• Garantía estatal inmutable: Las vistas de almacén siempre representan un estado coherente y puntual de los datos de Data 360.

Escenarios de integración complejos

• Modo híbrido: Combine Cero copia (para federación en vivo) con introducción (para conjuntos de datos históricos).
• Acceso entre almacenes: Data 360 puede federarse desde múltiples arrendatarios de Snowflake o Databricks en una organización.
• Interoperabilidad IA/BI: Los sistemas externos (por ejemplo, SageMaker, Tableau, Power BI) pueden consultar los perfiles enriquecidos de Data 360 a través de Cero copia inversa.
• Extensión Federación de archivos: Las empresas que adoptan formatos de lago abierto (Iceberg/Delta) pueden unificar datos estructurados y no estructurados bajo un modelo federado.

Ejemplo

Análisis entre nubes permite a las organizaciones combinar datos de Salesforce Data 360 gobernados con conjuntos de datos nativos en plataformas como Snowflake y Databricks para ofrecer una vista analítica completa de 360 grados. A través del acceso de múltiples arrendatarios, diferentes unidades comerciales pueden consumir de forma segura sectores de datos depurados y controlados por pólizas a través de colaboraciones separadas sin duplicar datos. Los científicos de datos pueden luego realizar IA federada y aprendizaje automático entrenando modelos directamente en perfiles de clientes unificados dentro de entornos de Snowflake ML o Databricks MLflow. A lo largo de este proceso, las funciones de linaje, gobernanza y auditoría integradas garantizan que todo el acceso y uso de datos siga cumpliendo con las políticas de la empresa y los requisitos normativos como el RGPD y la HIPAA.

Data Cloud One permite a las organizaciones con múltiples organizaciones de Salesforce (por ejemplo, debido a unidades comerciales, regiones, líneas de productos o adquisiciones) compartir una única instancia central de Data 360. Esta organización actúa como la “organización de inicio”, mientras que otras organizaciones, denominadas “organizaciones complementarias”, pueden acceder y actuar sobre esos datos unificados, con un esfuerzo mínimo, sin código personalizado y controles de gobernanza completos.

Contexto

Las empresas a menudo ejecutan más de una organización de Salesforce (por ejemplo, una para ventas, una para servicio, una para marketing o regiones distintas). Cada organización puede tener sus propios datos, configuración y procesos. Antes de Data Cloud One, cada organización requería su propia configuración de Data 360 o código personalizado complejo para compartir datos entre organizaciones. Data Cloud One simplifica esto permitiendo una única organización “inicio” con Data 360 y múltiples organizaciones “compañeras” que se conectan a través de configuración de código bajo y colaboración de metadatos.

Problema

¿Cómo puede un negocio permitir el uso coherente de los datos unificados de Customer 360 (introducidos, armonizados y gestionados por Data 360 de la organización de inicio) en todas sus organizaciones de Salesforce (de modo que ventas, marketing, servicio, etc., utilicen todos los mismos datos subyacentes), evitando al mismo tiempo la duplicación de esfuerzos, la codificación personalizada, las instancias de Data 360 separadas por organización y las brechas de gobernanza?

Fuerzas

Este patrón presenta múltiples consideraciones de arquitectura, seguridad y rendimiento:

• Complejidad entre organizaciones: La organización de cada unidad comercial puede tener diferentes datos, objetos personalizados, seguridad y procesos; mantener vistas unificadas coherentes es difícil.
• Duplicación y coste: Ejecutar una instancia de Data 360 separada por organización significa configuración adicional, regulación adicional, licencias adicionales y riesgo de silos de datos.
• Controles de gobernanza y colaboración de datos: Debe decidir qué datos puede ver cada organización complementaria y sobre qué acciones puede actuar: no puede simplemente compartir “todo” sin riesgo de gobernanza.
• Velocidad de configuración: Los equipos de marketing, ventas o servicio no pueden esperar semanas para que el código personalizado haga que los datos entre organizaciones estén disponibles; necesitan soluciones de configuración de clics.
• Residencia de datos, Consideraciones regionales: Si las organizaciones domésticas y complementarias están en diferentes regiones, puede haber restricciones legales o reglamentarias acerca de dónde se almacenan los datos o cómo se comparten.

Solución

La siguiente tabla contiene varias soluciones a este problema de integración.

Boceto

El siguiente diagrama ilustra la secuencia de eventos en este patrón, donde Salesforce es el principal de datos.

En este escenario:

• Administrador principal: cree Espacio de datos y defina Colaboración de datos (seleccione DMO/CIO, segmentos).
• Administrador de inicio: cree Objetivo de colaboración de datos para organizaciones complementarias y configure Trust (cliente de OAuth, identificadores de organización permitidos).
• Inicio Administrador: publique Colaboración de datos en destino; adjunte políticas de ABAC (CEDAR) y controles de cifrado/clave (CMK si es necesario).
• Administrador de organización complementaria: recibe la invitación, valida la asignación de identidad y acepta la colaboración.
• Organización de compañía: Data Cloud One Bridge aprovisiona un usuario de Data Cloud One y aplica Conjuntos de permisos y visibilidad de Espacio de datos.
• Aplicaciones de organización de compañía (Flujos / Einstein / Apex): Consulte un gráfico de datos o llame a las API de Data Cloud One para leer segmentos o DMO compartidos.
• Activación: La organización complementaria desencadena la activación o vuelve a escribir a través de acciones de datos (si se permite).

Resultados

• Una única fuente de verdad para datos de clientes (Customer 360) en todas las organizaciones conectadas: sin instancias de Data 360 redundantes.
• Las organizaciones complementarias pueden acceder a datos unificados y funciones con tecnología Data 360 en minutos, no semanas de codificación personalizada.
• Compartición de datos controlada. Solo se comparten los espacios de datos autorizados, lo que mantiene la seguridad y la gobernanza y permite la agilidad comercial.
• Las funciones comerciales (ventas, servicio, marketing) funcionan en la misma base de datos unificada, permitiendo mediciones coherentes, activación y perspectivas en toda la empresa.

Mecanismos de llamada

El mecanismo de llamada depende de la solución elegida para implementar este patrón.

Gestión y recuperación de errores

• Resistencia de sincronización entre organizaciones: Data Cloud One reintenta automáticamente trabajos de sincronización fallidos entre organizaciones de inicio y de acompañante utilizando retroceso exponencial para errores transitorios de red o plataforma.
• Aislamiento parcial por lotes: Los lotes de registros con fallos se ponen en cuarentena en una cola de reintento dentro de la organización de inicio hasta que la reconciliación se realice correctamente, evitando la divergencia de datos.
• Gobernanza de rechazo de esquema: Los desajustes de esquema o asignación se enrutan a la cola de rechazo de esquema para su revisión y corrección por parte del administrador.
• Continuidad de reproducción y reanudación: Cada trabajo de sincronización mantiene puntos de control de compensación de modo que la replicación pueda reanudarse desde la última confirmación correcta sin duplicación.
• Supervisión integrada: Todos los fallos, reintentos y mediciones de recuperación se capturan en el panel Trust Layer Monitoring para visibilidad y garantía de SLA.

Consideraciones de diseño idempotentes

• Claves de Idempotencia determinista: Cada evento de sincronización lleva una clave exclusiva (Id. de organización + Id. de registro + Número de versión) para garantizar el procesamiento exacto una vez.
• Seguridad de reproducción: Los eventos duplicados o reproducidos se filtran en tiempo de confirmación, garantizando actualizaciones de DMO y CIO descendentes coherentes.
• Semántica de confirmación atómica: Las organizaciones acompañantes marcan los datos como confirmados solo después de una escritura descendente correcta, preservando la integridad transaccional entre organizaciones.
• Resolución de conflictos: Las actualizaciones de múltiples orígenes siguen la lógica de combinación dirigida por políticas o las últimas ganancias, manteniendo el linaje y la coherencia.
• Persistencia de punto de control: Los trabajos de sincronización persisten en las compensaciones procesadas por última vez y se establecen en Trust Layer para una recuperación y reproducción seguras.

Consideraciones de seguridad

• Autenticación fuerte: Las conexiones entre organizaciones domésticas y de compañía utilizan OAuth 2.0 mutuo con tokens rotados automáticamente gestionados a través de aplicaciones conectadas.
• Autorización granular: Las organizaciones acompañantes solo pueden acceder a espacios de datos, DMO o CIO específicos compartidos explícitamente a través de políticas de colaboración de datos regidas.
• Cifrado en todas partes: Los datos se cifran en tránsito (TLS 1,2+) y en reposo (AES-256) entre organizaciones domésticas y de acompañante.
• Principio de privilegios mínimos: Los usuarios de integración solo tienen ámbito a los objetos requeridos; no se propagan permisos administrativos o a nivel del sistema.
• Visibilidad de auditoría y cumplimiento: Todos los eventos de sincronización, cambios de esquema, actualizaciones de credenciales y concesiones de acceso se registran en Data 360 Trust Layer para una trazabilidad completa.
• Aislamiento de red privado: Salesforce Private Connect o Vínculo privado opcionales garantizan que la replicación de datos se produzca únicamente en canales internos seguros.

Barras laterales

Oportunidad

• La sincronización entre las organizaciones de inicio y de acompañante se produce casi en tiempo real, normalmente en cuestión de segundos tras un cambio de datos en la organización de origen.
• La arquitectura de copia cero garantiza que los datos compartidos se puedan consultar al instante en todas las organizaciones participantes, sin replicación ni retrasos por lotes.
• Los trabajos de activación y segmentación reflejan automáticamente las actualizaciones más recientes desde cualquier organización conectada, manteniendo la actualización operativa.
• La latencia de extremo a extremo es determinista y se rige por las oportunidades en curso de orquestación de Data Cloud One, garantizando una puntualidad coherente entre organizaciones incluso bajo carga.

Volúmenes de datos

• Diseñado para la sincronización de datos a hiperescala de múltiples arrendatarios entre regiones y unidades comerciales, capaz de gestionar miles de millones de registros por organización.
• Se hace referencia a los datos, no se duplican, reduciendo la huella de almacenamiento mientras se mantiene la capacidad de consulta global.
• Los deltas de transmisión y la compactación de metadatos optimizan el ancho de banda y confirman los gastos generales para objetos de alto índice de cambio (por ejemplo, Contacto, Pedido).
• Se amplía horizontalmente entre múltiples organizaciones de compañía con equilibrio de carga adaptativo y orquestación a través de Trust Layer.

Gestión de estado

• Cada conjunto de datos sincronizado mantiene el linaje de metadatos, la versión y el contexto de propiedad de la organización para garantizar la trazabilidad de extremo a extremo.
• La persistencia de puntos de control captura compensaciones sincronizadas por última vez entre organizaciones, permitiendo la recuperación sin duplicación.
• La versión de esquemas y la alineación semántica entre organizaciones se rigen automáticamente por Trust Layers.
• No se requieren restablecimientos de estado manuales: el estado de sincronización se mantiene a través del Servicio de orquestación de Data Cloud One.

Escenarios de integración complejos

• Federación interinstitucional: Activación y consulta sencillas entre múltiples arrendatarios o regiones de Data 360 bajo un modelo de gobernanza unificado.
• Sincronización híbrida: Combina la replicación casi en tiempo real para actualizaciones transaccionales con la sincronización programada para datos masivos o de archivo.
• Gobernanza multirregional: Admite el uso compartido de datos distribuidos geográficamente respetando los límites de residencia, consentimiento y cumplimiento.
• Activación de IA y automatización: Los datos sincronizados potencian instantáneamente modelos de IA, Agentforce o ML personalizados de Einstein entre organizaciones, lo que permite la inteligencia entre organizaciones en tiempo real.

Ejemplo

Una organización minorista global tiene tres organizaciones de Salesforce: una para Consumer Retail, otra para Premium Brands y otra para International Markets. Aprovisionan Data 360 en la organización Consumer Retail (convirtiéndola en la organización de inicio). Con Data Cloud One, configuran conexiones complementarias con las organizaciones de Marcas Premium y Mercados internacionales. Solo comparten espacios de datos apropiados (por ejemplo, “Customer 360 - Retail Profiles” y “Customer 360 - Premium Profiles”) con cada organización complementaria. En la organización Premium Brands, los equipos de marketing pueden ver perfiles de clientes unificados, crear segmentos basándose en perspectivas calculadas (por ejemplo, valor de vida útil de cliente premium) y desencadenar automatizaciones de marketing, todo ello con tecnología de la instancia Data 360 de la organización de inicio, sin codificación personalizada o duplicación de datos.

La activación de datos es donde el valor de Salesforce Data 360 cobra vida realmente. Es el proceso de tomar los datos unificados, enriquecidos y gobernados que viven dentro de la plataforma y hacerlos funcionar en todo el negocio. En la práctica, esto significa entregar de forma segura segmentos depurados, perspectivas calculadas y atributos contextuales desde Data 360 en los sistemas que implican clientes, ya sea automatización de marketing, consolas de servicio, activación de ventas, análisis o modelos de IA. Desde una perspectiva técnica, los patrones de activación definen cómo se mueven estos datos: qué canales se desencadenan, qué transformaciones o asignaciones se producen y cómo se aplican las políticas en el camino. Estos patrones no solo se refieren a la exportación de datos, sino que se refieren a la orquestación de flujos de datos en tiempo real conscientes de las políticas que dirigen resultados comerciales mensurables. Cada ruta de activación convierte Customer 360 en un activo operativo en vivo, potenciando la personalización, las decisiones predictivas y el aprendizaje continuo en cada punto de contacto.

La activación por lotes sigue siendo el método más utilizado y probado operativamente para exportar datos desde Data 360. Funciona en una cadencia programada, publicando segmentos de audiencia predefinidos o conjuntos de atributos en plataformas descendentes a intervalos regulares. Este patrón es ideal para flujos de trabajo de marketing e implicación que se basan en entregas de audiencia coherentes y de gran volumen en vez de actualizaciones instantáneas. Los casos de uso habituales incluyen potenciar trayectorias de correo electrónico, campañas de correo directo o cargas de audiencia en redes de publicidad digital. Cada ejecución de activación extrae el segmento cualificado del gráfico de perfil unificado de Data 360, aplica políticas de gobernanza y consentimiento y transmite de forma segura el resultado al sistema de destino. Arquitectónicamente, la activación por lotes proporciona un enfoque predecible, auditable y rentable para la distribución de datos, equilibrando la simplicidad operativa con la fiabilidad de nivel empresarial. Es la columna vertebral de la ejecución de campañas a gran escala, donde los datos correctos, entregados a tiempo y bajo control, dirigen el impacto comercial mensurable.

Contexto

Los especialistas de marketing modernos operan en múltiples canales de implicación (correo electrónico, publicidad, móvil y web), cada uno demanda audiencias de clientes precisas, oportunas y personalizadas. Data 360 sirve como la base unificada para estas audiencias, combinando datos de clientes de cada sistema en segmentos enriquecidos y con capacidad de acción. La activación por lotes es el patrón de activación más común utilizado para exportar esos segmentos desde Data 360 a plataformas de marketing o publicidad descendentes. Los destinos habituales incluyen Marketing Cloud Engagement, Google Ads, Meta Custom Audiences o LinkedIn Ads, donde las campañas se pueden ejecutar directamente contra estas audiencias depuradas.

Problema

¿Cómo puede un equipo de marketing tomar una audiencia definida con precisión, creada utilizando datos unificados y enriquecidos en Data 360, y hacerla disponible en sistemas de marketing o publicidad externos para su activación? Por ejemplo, considere el segmento: “Clientes de alto valor que no compraron en los últimos 90 días pero que se implicaron recientemente en el sitio web”. Los especialistas de marketing necesitan asegurarse de que esta audiencia se transfiere con precisión, se enriquece con atributos relevantes (por ejemplo, nivel de fidelidad, región o CLV predicho) y se actualiza a intervalos regulares para mantener la relevancia y la eficacia de la campaña.

Fuerzas

Varios factores técnicos y operativos dan forma al patrón Activación por lotes:

• Asignación de identidad: Una entrega de audiencia precisa requiere asignar el Id. de Particular unificado de Data 360 al identificador correspondiente en el sistema de destino, como una Clave de suscriptor en Marketing Cloud o un correo electrónico de hash para plataformas publicitarias digitales. Esto garantiza una coincidencia precisa y elimina errores de objetivo.
• Selección y enriquecimiento de atributos: Los especialistas de marketing deben ir más allá de los Id. e incluir datos de perfil adicionales (como nombre, estado de fidelidad, CLV u otros atributos personalizados) para activar la personalización y el análisis descendentes.
• Configuración de plataforma de destino: Cada destino debe registrarse en Data 360 como un Destino de activación, incluyendo detalles de conexión, autenticación y asignaciones de campos de datos. Esta configuración puntual define la conectividad segura y rige qué sistemas pueden recibir datos activados.
• Gobernanza y cumplimiento: La activación de datos debe cumplir con los metadatos de consentimiento, las políticas de privacidad (por ejemplo, RGPD o CCPA) y los permisos de marketing almacenados en el perfil unificado. La activación consciente del consentimiento garantiza que los datos se utilicen solo para fines autorizados.
• Programación y rendimiento: Las activaciones a menudo se programan diariamente o cada hora para mantener actualizadas las audiencias descendentes. El sistema debe gestionar de forma eficiente grandes volúmenes y actualizaciones incrementales sin duplicación o pérdida de datos.

Solución

El proceso de activación por lotes en Data 360 sigue un flujo de trabajo guiado que minimiza las fricciones técnicas para los especialistas de marketing preservando al mismo tiempo la regulación y la capacidad de ampliación:

Boceto

Este es el resumen de los pasos:

• Segmento de construcción: Un especialista en marketing o analista crea un segmento utilizando una herramienta de segmentación visual, combinando filtros entre cualquier objeto de datos unificado.
• Crear activación: Seleccionan el segmento como un origen y eligen un destino preconfigurado (como Marketing Cloud o Google Ads).
• Definir carga: El identificador de contacto y otros atributos de perfil se eligen para la exportación y creación de informes de audiencia.
• Programar entrega: La activación está programada para ejecutarse una vez o de forma recurrente, manteniendo la audiencia en el destino actualizada.
• Ejecución: En el desencadenador, Data 360 consulta el segmento, construye la carga, aplica filtros para el consentimiento y envía el resultado al sistema de destino.

Resultados

• Los segmentos de audiencia enriquecidos y dirigidos desde Data 360 están disponibles directamente en plataformas de marketing y publicidad descendentes.
• Las audiencias se actualizan y sincronizan automáticamente con los datos de clientes unificados más recientes, manteniendo la relevancia de la campaña en tiempo real.
• Los especialistas de marketing pueden utilizar estas audiencias activadas como orígenes de entrada para trayectorias de Marketing Cloud, campañas de correo electrónico o audiencias personalizadas en plataformas publicitarias digitales como Google Ads, Meta o LinkedIn Ads.
• Cada ejecución de activación mantiene el linaje de extremo a extremo, garantizando el cumplimiento, la trazabilidad y la coherencia entre Data 360 y sistemas externos.
• Los usuarios comerciales pueden entregar experiencias altamente personalizadas dirigidas por datos con una vista Customer 360 completa y de confianza.

Mecanismos de llamada

El mecanismo de llamada depende de la plataforma de destino y la configuración de destino de activación.

Gestión y recuperación de errores

• Aislamiento de fallos a nivel de trabajo: Cada ejecución de activación se ejecuta como un trabajo rastreable distinto en la Capa de orquestación de Data 360. Las ejecuciones con fallos se ponen en cuarentena automáticamente sin afectar a otras activaciones o definiciones de segmentos.
• Recuperación parcial por lotes: Si ciertos registros no se exportan (por ejemplo, debido a desajustes de identificador o límites de frecuencia de API), el sistema los reintenta utilizando colas delta incrementales con retroceso exponencial y recuperación paralela.
• Errores de validación de esquemas: Cuando los atributos de carga salientes ya no coinciden con el esquema de destino (por ejemplo, un atributo eliminado o un campo renombrado), el trabajo enruta los registros afectados a la cola de rechazo de esquemas para su revisión por el administrador.
• Reproducir y reanudar asistencia: Cada trabajo de activación mantiene un token de punto de control, capturando el último lote realizado con éxito. Tras la recuperación, el procesamiento se reanuda desde el punto de control, garantizando que no haya duplicaciones o pérdida de datos.
• Supervisión integral: Todos los eventos de activación, reintentos y mediciones de entrega se registran en Trust Layer Monitoring, activando el seguimiento de SLA, el análisis de causa raíz y las alertas automatizadas a través de las API de Event Monitoring.

Consideraciones de diseño idempotentes

• Claves de activación determinista: Cada ejecución de activación utiliza una clave de idempotencia compuesta (combinando Id. de segmento, Id. de activación e Id. del sistema de destino) para garantizar la entrega exacta una vez.
• Detección de reproducción: El Servicio de activación de Data 360 inspecciona las cargas entrantes en hash de trabajos anteriores para detectar y suprimir repeticiones.
• La exportación atómica confirma: Las cargas se confirman en el sistema de destino solo después de una confirmación de escritura correcta, evitando actualizaciones parciales o recuento doble.
• Resolución de identidad coherente: Dado que las activaciones dependen de los Id. unificados (por ejemplo, Particular unificado), las repeticiones o reintentos siempre apuntan al mismo registro de oro, manteniendo la coherencia semántica.
• Persistencia de estado de activación: La capa de orquestación mantiene los metadatos de estado de activación (marcas de tiempo, códigos de estado y tokens de secuencia) para un reprocesamiento determinista si es necesario.

Consideraciones de seguridad

• Autenticación fuerte: Cada destino de activación (por ejemplo, Marketing Cloud, Ads o CRM) utiliza OAuth 2.0 con rotación de token y ámbito específico del arrendatario para evitar la exportación de datos no autorizada.
• Gobernanza a nivel de atributo: Solo los atributos aprobados desde el Perfil unificado son aptos para la activación, aplicada por Políticas de colaboración de datos y Plantillas de activación.
• Cifrado en tránsito y en reposo: Todas las cargas se cifran utilizando TLS 1.2+ durante la transferencia y AES-256 en reposo dentro de Data 360 y la plataforma de destino.
• Consentimiento y aplicación de políticas: Los trabajos de activación respetan los objetos de consentimiento y las políticas de datos almacenados en Trust Layer de Data 360. Los registros sin metadatos de consentimiento válido se excluyen automáticamente de la exportación.
• Registro de auditoría y cumplimiento: Cada ejecución de activación captura quién la inició, qué datos se enviaron y a qué destino, activando seguimientos de auditoría reguladora completos (RGPD, CCPA) en el panel Trust Layer.
• Acceso a menos privilegios: Los usuarios de integración para cada destino están restringidos a ámbitos específicos de activación, sin privilegios administrativos o acceso de escritura a sistemas no relacionados.

Barras laterales

Oportunidad

• Diseñado para exportaciones por lotes programadas o casi en tiempo real (latencia de minutos a horas).
• Admite actualizaciones con plazos de tiempo alineadas con calendarios de campaña.
• Los trabajos de activación se pueden secuenciar con marcadores de preparación de datos para garantizar la actualización de los datos.
• Mejor adaptado para escenarios de activación no interactivos donde la precisión de los datos supera la inmediatez.

Volúmenes de datos

• Gestiona conjuntos de datos a gran escala (millones de registros por ejecución).
• Se amplía horizontalmente a través de particiones de segmentos y canales de exportación paralelos.
• Emplea lotes basados en fragmentos para evitar tiempos de espera y optimizar el rendimiento.
• Ideal para oportunidades en curso de datos de nivel empresarial donde la integridad de los datos es crítica.

Gestión de estado

• Mantiene objetos de estado de activación registrando Id. de trabajo, marcas de tiempo y tokens de secuencia.
• Utiliza puntos de control para reiniciar y recuperar fallos.
• Las definiciones de segmentos versionados garantizan la reproducibilidad entre ciclos de activación.
• Activa la trazabilidad de linaje entre segmentos de origen, atributos de DMO y cargas de destino.

Escenarios de integración complejos

• Se integra perfectamente con Salesforce CRM, Marketing Cloud y sistemas externos a través de conectores preintegrados.
• Admite activaciones de múltiples objetivos, distribuyendo datos simultáneamente a diferentes destinos (por ejemplo, CRM + Ads).
• Puede desencadenar flujos de trabajo compuestos: por ejemplo, exportación por lotes seguida de llamada de API descendente o puntuación de IA.
• Gestiona la evolución de esquemas de forma elegante a través de la Capa de gobernanza de modelo de datos.

Ejemplo

Una marca minorista global desea volver a implicar clientes inactivos de los últimos 90 días. Utilizando Data 360, el arquitecto de datos define un segmento “Compradores latentes” enriquecido con historial de compras, nivel de fidelidad y metadatos de consentimiento. El Trabajo de activación por lotes se ejecuta cada noche, enviando este segmento a Marketing Cloud Engagement para desencadenar una campaña de correo electrónico personalizada “Te echamos de menos” y a Ad Studio para la reorientación. El trabajo aprovecha la entrega idempotente, garantizando que no haya duplicación entre reintentos, y todos los eventos se registran en Trust Layer para el cumplimiento de la auditoría.

Contexto

Las empresas a menudo requieren un mecanismo gobernado para exportar datos unificados o segmentados desde Salesforce Data 360 a un formato de archivo estándar (por ejemplo, CSV o Parquet) para la integración de archivado, cumplimiento o descendente. Este patrón activa la exportación de almacenamiento de Data 360 a la nube, permitiendo que los datos de clientes de confianza fluyan de forma segura a lagos de datos empresariales u oportunidades en curso de análisis alojadas en Amazon S3, Azure Blob o Google Cloud Storage (GCS). Los casos de uso habituales incluyen:

• Archivado periódico de conjuntos de datos de clientes consentidos para la retención reguladora.
• Exportación de segmentos depurados para cargas de trabajo analíticas que no sean de Salesforce (por ejemplo, Tableau, Databricks o Power BI).
• Activación de modelos de aprendizaje automático externos que requieren archivos CSV estructurados o Parquet como entrada.

Problema

¿Cómo puede una organización exportar un segmento o conjunto de datos depurado desde Data 360 a un depósito de almacenamiento en la nube (por ejemplo, Amazon S3), de una forma gobernada, segura y automatizada, mientras mantiene la integridad del esquema y los controles de cumplimiento? Por ejemplo, un equipo de cumplimiento puede necesitar: “Extraiga todos los clientes activos en la región de la UE con un consentimiento válido y exporte los datos semanalmente a una ubicación S3 para auditoría externa y creación de informes.” Esto requiere una canalización de exportación repetible y consciente de las políticas que garantice el formato de archivo, los permisos de acceso y la programación de entrega correctos, sin intervención manual o movimiento de datos no controlado.

Fuerzas

Múltiples factores operativos y arquitectónicos rigen este patrón de exportación:

• Autenticación y autorización: Las exportaciones deben respetar el modelo IAM del proveedor de nube (por ejemplo, Funciones IAM de AWS o Principales de servicio de Azure) para garantizar que solo los sistemas autorizados pueden escribir en el depósito de destino.
• Alineación de esquema: El esquema saliente debe coincidir con la estructura y el formato esperados del sistema de destino (CSV, Parquet o JSON).
• Privacidad y consentimiento: Los conjuntos de datos exportados deben filtrar cualquier registro que carezca de metadatos de consentimiento válidos.
• Programación y actualización: Muchas exportaciones son periódicas (diarias, semanales o mensuales) y deben alinearse con los ciclos de actualización de datos de la empresa.
• Gobernanza y supervisión: Cada exportación debe ser auditable con visibilidad de linaje completa, garantizando el cumplimiento de los mandatos de retención y regulación de datos (por ejemplo, RGPD, CCPA).

Solución

El patrón Activación de exportación de archivos reutiliza los mismos conectores de almacenamiento en la nube seguros empleados para la introducción pero configurados para la salida de datos. Los administradores primero registran la plataforma de almacenamiento en la nube (por ejemplo, Amazon S3, Azure Blob Storage o GCS) como un Destino de activación en Data 360. A continuación, los usuarios configuran y ejecutan un flujo de trabajo de activación para exportar el segmento que deseen a la ruta de almacenamiento de archivos designada.

Boceto

Este es el resumen de los pasos.

• Seleccionar segmento: Un analista o administrador de datos elige el segmento unificado para exportar.
• Crear activación: Crean un nuevo trabajo Activación y seleccionan el destino de Almacenamiento en nube registrado.
• Definir carga: Especifique el esquema de exportación, la lista de atributos y el formato de archivo (por ejemplo, CSV).
• Programar exportación: Seleccione una programación puntual o recurrente.
• Ejecutar trabajo: Data 360 genera y entrega de forma segura el archivo a la ruta de depósito designada.
• Supervisar y verificar: Los resultados y registros se revisan en Trust Layer para su validación y cumplimiento.

Resultados

• Los segmentos de audiencia enriquecidos y dirigidos desde Data 360 están disponibles directamente en plataformas de marketing y publicidad descendentes.
• Las audiencias se actualizan y sincronizan automáticamente con los datos de clientes unificados más recientes, manteniendo la relevancia de la campaña en tiempo real.
• Los especialistas de marketing pueden utilizar estas audiencias activadas como orígenes de entrada para trayectorias de Marketing Cloud, campañas de correo electrónico o audiencias personalizadas en plataformas publicitarias digitales como Google Ads, Meta o LinkedIn Ads.
• Cada ejecución de activación mantiene el linaje de extremo a extremo, garantizando el cumplimiento, la trazabilidad y la coherencia entre Data 360 y sistemas externos.
• Los usuarios comerciales pueden entregar experiencias altamente personalizadas dirigidas por datos con una vista Customer 360 completa y de confianza.

Mecanismos de llamada

El mecanismo de llamada depende de la plataforma de almacenamiento en la nube de destino y la configuración de activación.

Gestión y recuperación de errores

• Aislamiento a nivel de trabajo: Cada exportación se ejecuta como un trabajo discreto. Los trabajos fallidos se ponen en cuarentena y se reintentan de forma independiente.
• Reintento de archivo parcial: Si ciertos lotes no se cargan (por ejemplo, debido a interrupciones de red), el sistema reintenta esos fragmentos utilizando retroceso exponencial.
• Gestión de desajustes de esquema: Cualquier desviación de esquema o desajuste de campo enruta registros a la cola de rechazo de esquema para su revisión.
• Punto de control y reanudación: Los trabajos de exportación mantienen metadatos de puntos de control, permitiendo la reanudación desde la última escritura correcta sin duplicación.
• Supervisión integrada: Los fallos y reintentos se registran en el panel Trust Layer para la visibilidad y el cumplimiento del SLA.

Consideraciones de diseño idempotentes

• Claves de exportación deterministas: Cada trabajo de exportación incluye un Id. exclusivo compuesto de Id. de segmento + Id. de destino + Marca de tiempo.
• Seguridad de reproducción: Las ejecuciones de trabajos duplicados se detectan utilizando hash de trabajos y se omiten para evitar exportaciones redundantes.
• Garantía de escritura atómica: Data 360 confirma archivos en el depósito de destino solo después de la finalización completa y validación de suma de control.
• Versión de esquema coherente: Las definiciones de exportación están controladas por versión para garantizar la coherencia de esquemas entre ejecuciones.
• Persistencia de punto de control: Los trabajos de exportación persisten para recuperación determinista y reprocesamiento si es necesario

Consideraciones de seguridad

• Autenticación fuerte: Los conectores de nube utilizan OAuth 2.0, funciones IAM o principales de servicio para escrituras autenticadas.
• Cifrado en todas partes: Los datos se cifran tanto en tránsito (TLS 1,2+) como en reposo (AES-256).
• Exportación consciente del consentimiento: Solo se exportan registros con consentimiento válido, aplicados por políticas de Trust Layer.
• Principio de privilegios mínimos: Los usuarios de exportación y las cuentas de servicio están restringidos a sus rutas de almacenamiento designadas.
• Registro de auditoría integral: Cada exportación registra metadatos incluyendo iniciador, esquema, destino y marcas de tiempo para la creación de informes de cumplimiento.

Barras laterales

Oportunidad

• Diseñado para activación inmediata dirigida por eventos con latencia de subsegundos.
• Ideal para escenarios que requieren personalización instantánea, recomendación o decisión.
• Funciona en modo de transmisión: los desencadenadores se activan en cuanto se producen cambios de datos de cualificación en Data 360.
• Garantiza una capacidad de respuesta continua sin esperar programaciones por lotes o recalculación de segmentos.

Volúmenes de datos

• Gestiona conjuntos de datos a gran escala (millones de registros por ejecución).
• Se amplía horizontalmente a través de particiones de segmentos y canales de exportación paralelos.
• Emplea lotes basados en fragmentos para evitar tiempos de espera y optimizar el rendimiento.
• Ideal para oportunidades en curso de datos de nivel empresarial donde la integridad de los datos es crítica.

Gestión de estado

• Cada acción de evento mantiene su propio token de eventos e Id. de reproducción para un procesamiento idempotente.
• Admite la persistencia del punto de control para reanudar desde el último evento confirmado en caso de fallo transitorio.
• Incluye lógica de deduplicación integrada y plazos de reproducción para garantizar una semántica de activación puntual exacta.
• Los resultados de la acción (éxito/fallo) se registran en tiempo real y afloran a través del panel de observabilidad de Trust Layer.

Escenarios de integración complejos

• Se integra directamente con Salesforce Flows, Eventos de plataforma Einstein 1 o webhooks externos para cadenas de respuesta instantánea.
• Puede desencadenar automatizaciones descendentes: por ejemplo, actualizaciones de registros de CRM instantáneas, puntuación de IA o envíos de mensajes de Marketing Cloud.
• Admite orquestación componible: los desencadenadores de eventos pueden llamar Acciones de Data 360, invocaciones Apex o API externas.
• Diseñado para patrones empresariales agentes y adaptativos donde las respuestas conscientes del contexto deben producirse al instante.

Ejemplo

Una empresa minorista global necesita entregar una exportación semanal de su segmento “Miembros de fidelidad activos” para su análisis en Databricks. El administrador de Data 360 configura Amazon S3 como un destino de activación y programa una exportación semanal de CSV a la ruta de s3://enterprise-analytics/loyalty/weekly_exports/. El trabajo de exportación se ejecuta cada domingo, generando un archivo filtrado de consentimiento con más de 2 registros. Todos los eventos, definiciones de esquema y linaje se registran en el panel Trust Layer, garantizando la transparencia, la capacidad de auditoría y el cumplimiento.

Activación basada en API On-Demand es un enfoque en tiempo real dirigido por eventos para hacer que las perspectivas de Data 360 sean procesables en el momento en que se necesitan, sin esperar trabajos por lotes o exportaciones programadas. En vez de publicar segmentos preintegrados en una cadencia fija, este patrón permite a sistemas externos, aplicaciones de Salesforce o agentes de IA llamar a las API de Data 360 directamente para obtener o activar sectores de audiencia específicos, atributos de clientes o perspectivas on demand. Este patrón está diseñado para experiencias interactivas basadas en desencadenadores, como cuando un usuario inicia sesión en un portal, un agente abre un registro de cliente o un copiloto de IA inicia una consulta de la siguiente mejor acción. En vez de depender de exportaciones precalculadas, el sistema consulta o activa de forma dinámica los datos gobernados más actuales desde Data 360 en tiempo real. La ventaja clave es la inmediatez y precisión:

• Cada llamada de API accede a la Inteligencia de clientes más actualizada en el gráfico de perfil unificado de Data 360 que reconoce el consentimiento.
• Las activaciones son idempotentes y auditables, alineándose con Enterprise Trust y los requisitos de cumplimiento.
• Las integraciones se pueden desencadenar directamente desde Salesforce Flows, Apex o sistemas externos a través de las API de plataforma Einstein 1, las API de Connect o las API de activación. Este enfoque admite casos de uso donde la latencia y la personalización son más importantes, por ejemplo:
• Desencadenar una oferta de producto personalizada durante una llamada de servicio.
• Generación de audiencias de campaña dinámicas basándose en eventos de comportamiento en vivo.
• Alimentar decisiones en tiempo real en modelos de IA o ML que funcionan en el momento de la implicación.

Contexto

Las empresas a menudo necesitan aflorar perspectivas armonizadas en tiempo real de Data 360 en aplicaciones creadas a medida, como portales web internos, aplicaciones móviles o experiencias web de cara al socio. Este patrón permite a los desarrolladores crear soluciones seguras centradas en la interfaz de usuario que consumen y muestran datos de clientes unificados junto con Salesforce CRM y otros sistemas contextuales, todo a través del acceso gobernado y basado en API. Los casos de uso habituales incluyen:

• Integración de perspectivas de Data 360 en paneles de empleados internos o aplicaciones móviles.
• Creación de portales de socios o concesionarios con visibilidad de clientes y transacciones.
• Integración de datos de Data 360 en aplicaciones web externas o capas de experiencia.
• Visualización de recomendaciones personalizadas en tiempo real con tecnología de Data 360 y Einstein 1.

Problema

¿Cómo puede un desarrollador crear una aplicación personalizada centrada en la interfaz de usuario que accede y muestra de forma segura datos armonizados de Data 360, a menudo junto con otras fuentes de datos de Salesforce, sin duplicar o exportar información confidencial? Por ejemplo, una empresa puede necesitar crear un portal de clientes que muestre perfiles de clientes unificados, interacciones y perspectivas calculadas desde Data 360. Esto requiere una capa de API única, segura y con rendimiento que pueda potenciar la experiencia de front-end, gestionar la autenticación y garantizar la gobernanza, al tiempo que elimina la complejidad del modelo de datos interno de Data 360.

Fuerzas

Múltiples consideraciones arquitectónicas y operativas influyen en este patrón:

• Acceso centrado en la interfaz de usuario: El objetivo principal es aflorar datos en experiencias front-end personalizadas (web o móviles), no realizar la extracción por lotes o sincronizaciones backend.
• Puerta de enlace segura: La API elegida debe servir como un punto de entrada seguro y ampliable para aplicaciones y usuarios autenticados, aplicando controles de acceso de nivel empresarial.
• Contexto de datos unificados: Las aplicaciones deben poder combinar datos de Data 360 (por ejemplo, perfiles unificados, perspectivas calculadas) con CRM, ERP o datos de objetos personalizados de forma sencilla.
• Developer Simplicity: Las API deben devolver cargas listas para presentaciones que minimicen el procesamiento backend o la asignación de esquemas en la capa de cliente.
• Gobernanza y observabilidad: Todo el acceso debe fluir a través de canales de confianza auditables con un linaje, autenticación y aplicación de políticas claros.

Solución

La solución es utilizar la API REST de Salesforce Connect como la pasarela de integración principal para crear aplicaciones personalizadas dirigidas por datos sobre Data 360. La API de Connect proporciona acceso RESTful a datos de Salesforce, incluyendo perfiles armonizados, segmentos y perspectivas calculadas de Data 360, en formatos de respuesta optimizados para el consumo de la interfaz de usuario (basados en JSON, ligeros y compatibles con dispositivos móviles). Los desarrolladores se autentican a través de una aplicación conectada, obtienen tokens de OAuth 2.0 y llaman a recursos de API de Connect como /query, /Chatter o /data para aflorar datos unificados directamente en sus interfaces de aplicación. En segundo plano, la API de Connect sirve como base de transporte para otras API, como la API de consulta, la API de gráfico de datos y las API de plataforma Einstein 1, permitiendo a los desarrolladores combinar múltiples orígenes de datos bajo un patrón de acceso unificado.

Boceto

Este es el resumen de los pasos.

• Registrar aplicación conectada: Defina ámbitos de OAuth y permisos de API para la autenticación de aplicaciones externas.
• Obtener token de acceso: La aplicación externa realiza la autenticación de OAuth 2.0 para recibir un token para el acceso a Data 360.
• Invocar API de Connect: La aplicación realiza llamadas de API de REST para recuperar datos de perfil, segmento o perspectiva unificados.
• Renderizar datos en interfaz de usuario: Las respuestas se analizan y se presentan a los usuarios en un portal con marca o interfaz móvil.
• Gestionar errores y tokens de actualización: Las aplicaciones implementan lógica de reintento y actualización de token automática para la continuidad de la sesión.
• Acceso de supervisión y auditoría: Todas las llamadas de API se registran en Trust Layer para visibilidad y cumplimiento.

Resultados

Los desarrolladores pueden crear aplicaciones seguras con marca personalizada estrechamente integradas con Data 360. Estas aplicaciones pueden:

• Aflore perspectivas y perfiles de clientes armonizados en tiempo real.
• Muestre datos de Data 360 junto con CRM u objetos personalizados a través de API unificadas.
• Aproveche los controles de autenticación, autorización y auditoría coherentes a través de Trust Layer.
• Proporcione a los usuarios comerciales o socios un acceso sencillo y controlado a Inteligencia de clientes de confianza entre experiencias.

Mecanismos de llamada

El mecanismo de llamada depende de la plataforma de almacenamiento en la nube de destino y la configuración de activación.

Gestión y recuperación de errores

• Solicitud de aceleración: Retrocede automáticamente y reintenta llamadas de API bajo límites de frecuencia.
• Protección contra deriva de esquemas: Utiliza la versión de esquemas de GraphQL o el descubrimiento de metadatos de REST para adaptarse a cambios de esquemas.
• Gestión de vencimiento de tokens: Las aplicaciones actualizan tokens de OAuth automáticamente para evitar interrupciones de sesión.
• Aislamiento de fallos de API: las llamadas de API fallidas se registran y se reintentan sin afectar a las sesiones simultáneas.
• ** Trust Layer Observability**: Los índices de éxito/fracaso de API y los registros de acceso son visibles en el panel Trust Layer.

Consideraciones de diseño idempotentes

• Identificadores de solicitudes deterministas: Cada solicitud de API incluye un Id. de correlación para un procesamiento seguro para la reproducción.
• Encabezados de validación de caché: Los encabezados ETag y Última modificación evitan las recuperaciones de datos redundantes.
• Operaciones de lectura atómica: La API de Connect garantiza que cada respuesta refleje una instantánea coherente de datos unificados.
• Protección de reproducción: Las llamadas de API duplicadas se filtran utilizando firmas de solicitud y marcas de tiempo.

Consideraciones de seguridad

• Autenticación de OAuth 2.0: Todas las llamadas de API utilizan tokens de acceso de OAuth seguros y de corta duración a través de aplicaciones conectadas.
• Acceso a menos privilegios: Los ámbitos de API están restringidos únicamente a los objetos y campos necesarios.
• Cifrado en todas partes: TLS 1,2+ en tránsito; cifrado AES-256 en reposo para respuestas almacenadas o en caché.
• Acceso a datos consciente del consentimiento: Data 360 garantiza que todos los registros recuperados se adhieren a las políticas de consentimiento y regulación.
• Registro de auditoría integral: Cada interacción de API se registra con metadatos de usuario, aplicación y marca de tiempo en Trust Layer.

Barras laterales

Oportunidad

• Diseñado para acceso de API en tiempo real de baja latencia.
• Ideal para aplicaciones interactivas que requieren representación de datos inmediata.
• Admite tiempos de respuesta de consultas casi instantáneos a través de orígenes de Data 360 en caché e indexados.
• Sin dependencia de programaciones por lotes o ciclos de activación asíncronos.

Volúmenes de datos

• Optimizado para casos de uso interactivos que obtienen conjuntos de datos pequeños a medianos (por ejemplo, perfiles, perspectivas o transacciones recientes).
• Gestiona los resultados paginados correctamente a través de paginación basada en cursor.
• No pensado para exportaciones masivas de gran volumen: utilice patrones de exportación por lotes o de archivos para conjuntos de datos de gran tamaño.

Gestión de estado

• Las aplicaciones mantienen un estado de sesión ligero con tokens de OAuth y caché local.
• La API de Connect admite solicitudes condicionales y actualización parcial para mayor eficiencia.
• Las respuestas de API incluyen marcadores de versión para la coherencia de esquemas entre versiones.

Escenarios de integración complejos

• Combine la API de Connect con la API de gráfico de datos para consultas semánticas entre múltiples dominios.
• Integre con las API de Copiloto o IA de Einstein 1 para experiencias predictivas y de conversación.
• Utilice junto con Experience Cloud o Componentes web Lightning para el desarrollo de la interfaz de usuario híbrida.
• Amplíe a través de MuleSoft para orquestar búsquedas de enriquecimiento de datos o sistemas externos en tiempo real.

Ejemplo

Una empresa aseguradora multinacional crea un portal de autoservicio de clientes que permite a los asegurados ver sus perfiles unificados, reclamaciones recientes y ofertas personalizadas. La aplicación front-end basada en hechos se autentica a través de OAuth 2.0 y recupera datos utilizando la API de REST de Connect y la API de gráfico de datos. Todos los datos se muestran en tiempo real, conscientes del consentimiento y gobernados a través de la capa de confianza Data 360 Trust. Los desarrolladores supervisan llamadas de API y seguimientos de auditoría directamente dentro de Salesforce, garantizando el cumplimiento y la observabilidad completos.

Contexto

Las empresas requieren cada vez más acceso instantáneo a un perfil de cliente completo para sistemas de decisión en tiempo real, como consolas de servicio, motores de recomendación o plataformas de personalización. Este patrón permite a las aplicaciones recuperar vistas unificadas precalculadas de los datos de un cliente en tiempo casi real utilizando la API de Data Graph de Data 360, proporcionando tiempos de respuesta de subsegundos para experiencias interactivas. Los casos de uso habituales incluyen:

• Visualización de una vista de cliente de 360 grados en Servicio al cliente o Sales Console.
• Potenciación de recomendaciones basadas en IA “Next Best Action” o “Next Best Offer”.
• Entrega de experiencias web o móviles hiperpersonalizadas en tiempo de carga de página.
• Compatibilidad con decisiones en sesión en entornos de agentes o autoservicio.

Problema

¿Cómo puede una aplicación recuperar una vista de cliente completa, precalculada y unificada al instante, en vez de ejecutar consultas lentas de múltiples objetos en tiempo de ejecución? Por ejemplo, un motor de personalización web debe cargar el contexto completo del cliente (datos demográficos, preferencias, transacciones y perspectivas calculadas) en milisegundos para seleccionar una oferta personalizada. Las consultas relacionales tradicionales pueden requerir múltiples uniones y dar como resultado una latencia inaceptable. Esto requiere una API que ofrezca datos de perfil desnormalizados y listos para su uso, recuperables a través de una única búsqueda de claves, combinando velocidad, integridad y regulación.

Fuerzas

Múltiples factores operativos y de rendimiento influyen en este patrón:

• Velocidad: El tiempo de respuesta debe ser casi en tiempo real. La API debe devolver un perfil completo en milisegundos para admitir interacciones síncronas.
• Completitud: La respuesta debe incluir todos los atributos, relaciones y perspectivas calculadas relevantes, idealmente en una única carga.
• Eficiencia de búsqueda: Los perfiles deben ser recuperables a través de identificadores como customerId, contactKey o correo electrónico, eliminando consultas de múltiples pasos.
• Actualización de datos frente a Latencia: Algunos casos de uso prefieren datos precalculados (en caché) para la velocidad; otros necesitan datos en vivo, aceptando mayor latencia.
• Gobierno y seguridad: El acceso debe permanecer gobernado a través de políticas de Salesforce Trust Layer, garantizando el cumplimiento de las reglas de visibilidad y consentimiento de los datos.

Solución

La solución es utilizar la API de Salesforce Data Graph para recuperar vistas de clientes desnormalizadas precalculadas almacenadas como registros de Data Graph. Un Gráfico de datos es una vista semántica materializada que combina múltiples Objetos de modelo de datos (DMO) (como Particular, Transacción e ProductInterest) en un único registro de solo lectura, a menudo representado como un blob de JSON. Los desarrolladores pueden utilizar extremos de REST como: GET /api/v1/dataGraph/{dataGraphEntityName}/{id} para recuperar un registro completo por su identificador exclusivo. Para escenarios dinámicos, la API admite un parámetro live=true que omite la caché materializada, ejecutando una consulta en tiempo real entre Data 360, intercambiando una latencia mínima por los datos más actualizados. Esto permite a los desarrolladores seleccionar entre recuperaciones de perfiles instantáneas (en caché) y al momento (en vivo) dependiendo de las necesidades comerciales.

Boceto

Este es el resumen del flujo de implementación:

• Definir gráfico de datos: Los arquitectos de datos crean un gráfico de datos que modela una vista de cliente unificada entre múltiples DMO.
• Registrar aplicación conectada: Los desarrolladores configuran credenciales de OAuth para un acceso seguro a la API.
• Invocar API de gráficos de datos: La aplicación emite una solicitud GET con el nombre del gráfico de datos y el Id. de registro.
• Respuesta del proceso: La API devuelve una representación JSON completa del perfil de cliente.
• Render o Act: La aplicación que consume (interfaz de usuario o motor) utiliza los datos unificados para la personalización, recomendaciones o acciones de servicio.
• Supervisar y ajustar: Las mediciones de rendimiento y los registros de acceso se revisan a través de la consola de observabilidad Trust Layer.

Resultados

Las aplicaciones ahora pueden recuperar un perfil de cliente completo preunido al instante, potenciando interacciones en tiempo real como la personalización, el servicio y la automatización de decisiones. Este patrón garantiza:

• Tiempos de respuesta por debajo del segundo para la decisión en el momento.
• Recuperación de datos gobernada coherente alineada con el modelo semántico Data 360.
• Lógica de aplicación simplificada: sin uniones, sin reconciliación de esquemas.
• Acceso rastreable y compatible a través de Trust Layer para auditoría y observabilidad.

Mecanismos de llamada

El mecanismo de llamada depende de la plataforma de almacenamiento en la nube de destino y la configuración de activación.

Gestión y recuperación de errores

• Respaldos agraciados: Si las consultas en vivo fallan o superan los umbrales de tiempo de espera, vuelva automáticamente a las recuperaciones de gráficos de datos en caché.
• Gestión de tiempo de espera: Implemente lógica de reintento e interruptor para llamadas de API bajo alta carga.
• Gestión de Id. no válida: devuelve respuestas estándar 404 No encontradas para claves de perfil inexistentes; gestiona correctamente en la interfaz de usuario.
• Validación de versión de esquema: Valide metadatos de versión de gráfico de datos para evitar desajustes cuando evoluciona el esquema.
• Integración de observabilidad: registre todos los errores, reintentos y latencias en paneles Trust Layer para la supervisión de SLA.

Consideraciones de diseño idempotentes

• Claves deterministas: Cada recuperación de perfil utiliza un Id. estable (por ejemplo, IndividualId) garantizando consultas predecibles y seguras de reproducción.
• Coherencia de caché: Utilice encabezados ETag o Última modificación para recuperaciones condicionales y validación de caché.
• Recuperación atómica: Cada respuesta de API representa una instantánea coherente del registro Gráfico de datos materializado.
• Protección de reproducción: Asegúrese de que las aplicaciones cliente detectan recuperaciones duplicadas a través de identificadores de correlación y marcas de tiempo.

Consideraciones de seguridad

• Autenticación sólida: OAuth 2.0 a través de aplicaciones conectadas aplica acceso seguro basado en tokens.
• Recuperación consciente del consentimiento: Solo se devuelven atributos consentidos; los filtros de consentimiento se aplican por Trust Layer automáticamente.
• Gobernanza a nivel de campo: El acceso a los atributos se controla a través de los metadatos y las definiciones de políticas de Data 360.
• Cifrado en tránsito y en reposo: Todas las respuestas están cifradas con TLS 1.2+ y AES-256.
• Auditoría y trazabilidad: Cada evento de recuperación de perfil se registra con identificadores, marcas de tiempo y contexto de política.

Barras laterales

Oportunidad

• Diseñado para la recuperación instantánea.
• Admite consultas en vivo para datos actualizados con latencia ligeramente superior (subsegundo).
• Optimizado para decisiones síncronas y aplicaciones interactivas.
• Elimina la necesidad de activación previa al lote o recálculo de segmentos.

Volúmenes de datos

• Ideal para búsquedas de registro único o conjuntos pequeños (de decenas a cientos) por solicitud.
• No está optimizado para la recuperación masiva a gran escala; utilice las API por lotes o de consulta para lecturas de gran volumen.
• Emplea almacenamiento en caché y materialización previa ampliables horizontalmente para mayor velocidad.

Gestión de estado

• Mantiene un acceso ligero y sin estado; cada solicitud es independiente.
• Admite el almacenamiento en caché de encabezados para una recuperación segura.
• Las aplicaciones pueden mantener caché local o almacenamiento de sesiones a corto plazo para reducir las búsquedas repetidas.

Escenarios de integración complejos

• Se integra perfectamente con Einstein 1, Connect API y MuleSoft para experiencias de datos compuestos.
• Puede alimentar sistemas genéticos (por ejemplo, motores de razonamiento de copiloto o IA) que requieren una conciencia instantánea y contextual.
• Combinado con acciones de datos para desencadenadores en tiempo real tras la recuperación o el cambio de estado.
• Permite la personalización a escala sin comprometer el rendimiento o la gobernanza.

Ejemplo

Una plataforma de comercio electrónico global utiliza la API Data Graph de Data 360 para recuperar perfiles de clientes unificados en tiempo real para su motor de recomendaciones. Cuando un usuario inicia sesión, la aplicación invoca el extremo Gráfico de datos para obtener el UnifiedCustomerProfile para ese cliente, devolviendo atributos demográficos, señales de comportamiento y perspectivas calculadas como una única carga JSON. El motor de personalización consume esta respuesta en milisegundos para determinar y mostrar la “Siguiente mejor oferta” durante la sesión activa. Todas las solicitudes se rigen y se registran a través de la Confideience Layer, garantizando la visibilidad completa, la aplicación de políticas y el cumplimiento en toda la interacción.

Las acciones de datos en tiempo real permiten la activación instantánea de datos de clientes en el momento en que cambian en Data 360. En vez de esperar exportaciones por lotes programadas, estas acciones envían actualizaciones, perspectivas o desencadenadores directamente a Salesforce o sistemas externos en milisegundos. Cuando se actualiza la medición de estado, consentimiento o implicación de un cliente en Data 360, esa señal puede activar inmediatamente ofertas personalizadas, desencadenar automatizaciones de Service Cloud o actualizar niveles de fidelidad, garantizando que cada experiencia del cliente refleja la verdad más actual y unificada. Este patrón es ideal para casos de uso de alto impacto y sensibles a la latencia como experiencias web personalizadas, alertas de detección de fraude, recomendaciones de la siguiente mejor acción o actualizaciones de CRM en tiempo real. Cierra la brecha entre la perspectiva de datos y la acción comercial, convirtiendo los datos unificados en inteligencia en el momento.

Contexto

Las experiencias digitales modernas y los flujos de trabajo operativos requieren acciones contextuales inmediatas en el momento en que se produce un evento: por ejemplo, actualizar un registro de cliente durante un Checkout, ajustar el inventario cuando se escanea una devolución o entregar una promoción personalizada en el instante en que un usuario abandona un carrito. Las acciones de datos en tiempo real permiten a los sistemas invocar, enriquecer y actuar sobre perfiles de Data 360 unificados y perspectivas calculadas con latencia de subsegundo a segundo, permitiendo la personalización interactiva, la automatización operativa y la decisión instantánea.

Problema

¿Cómo pueden las aplicaciones, los flujos de interacción de la interfaz de usuario o el middleware llamar a Data 360 en tiempo de ejecución para leer, calcular o actualizar un perfil unificado único o desencadenar una acción (por ejemplo, enviar una oferta, actualizar CRM, iniciar un flujo de trabajo) con baja latencia, fuerte coherencia y controles de regulación, sin esperar trabajos por lotes programados u oportunidades en curso pesadas?

Fuerzas

Varias fuerzas técnicas, operativas y de gobernanza dan forma a este patrón:

• Requisito de baja latencia: Las llamadas deben completarse en un intervalo de subsegundos a unos segundos para preservar un buen UX o para cumplir los SLA operativos.
• Resolución de identidad determinista: Las solicitudes deben resolverse en el perfil Particular unificado correcto (registro de oro) de forma fiable y rápida.
• Autorización precisa: Las llamadas en tiempo real deben aplicar políticas a nivel de atributo y comprobaciones de consentimiento en el momento de la solicitud.
• Minimización de carga: Las cargas en tiempo real deben ser pequeñas y centradas (perfil único o conjunto de atributos pequeño) para reducir la latencia y el coste.
• Experiencia de desarrollador: Las API deben ser fáciles de desarrollar (REST/gRPC/GraphQL), con esquemas claros y contratos estables para el uso de producción.
• Auditabilidad y trazabilidad: Cada acción en tiempo real debe registrarse con linaje, identidad de usuario y decisiones de política para el cumplimiento.

Solución

La solución recomendada es utilizar la interfaz de Acciones de datos en tiempo real (API + SDK) de Data 360 combinada con almacenamiento en caché periférico y transformaciones de cálculo mínimas donde sea necesario. Las integraciones invocan un extremo de acciones de datos para leer o escribir atributos de perfil, calcular perspectivas o iniciar orquestaciones. Las comprobaciones de políticas en tiempo real (CEDAR) y el enmascaramiento dinámico se aplican en el Punto de aplicación de políticas antes de que se devuelva cualquier carga o se ejecute una acción.

Boceto

Este es el resumen de los pasos.

• El cliente (UI / middleware / POS) envía solicitudes de acciones de datos autenticadas con identificadores y tipo de acción.
• La pasarela de API valida tokens, límites de frecuencia y reenvía a Servicio de acción de Data 360.
• Action Service resuelve identificador → Id. de Particular unificado (caché de ruta rápida; reserva a búsqueda de gráfico).
• Aplicación de políticas (PDP) evalúa políticas de CEDAR utilizando atributos de PIP y contexto de solicitud.
• Si se permite, Action Service lee cualquier atributo/perspectiva de perfil requerido y realiza transformaciones de luz.
• Action Service devuelve respuesta de forma síncrona (por ejemplo, token de oferta, atributo actualizado) o pone en cola la orquestación asíncrona y devuelve confirmación.
• Todos los eventos, decisiones y cargas se registran en Trust Layer y se reenvían opcionalmente a SIEM.

Resultados

• Las aplicaciones reciben acceso inmediato, gobernado por políticas, a lecturas/escrituras de perfiles unificados y desencadenadores de acciones con latencia de subsegundo a segundo.
• Los flujos de trabajo operativos, de decisión y de personalización en tiempo real (por ejemplo, ofertas, asistencia de agentes, actualizaciones de inventario) están activados sin retrasos por lotes.
• Todas las acciones son auditables, conscientes del consentimiento y aplican el enmascaramiento a nivel de atributos para mantener la privacidad y el cumplimiento.

Mecanismos de llamada

El mecanismo de llamada depende de la plataforma de destino y la configuración de destino de activación.

Gestión y recuperación de errores

• Errores síncronos: Devuelva códigos de error estructurados con mensajes legibles por personas y tokens de idempotencia.
• Reintento transitorio: Los clientes deben reintentar solicitudes idempotentes con retroceso exponencial en respuestas 429/5xx.
• Gestión de denegación de política: Las denegaciones devuelven códigos de motivo claros; los datos confidenciales nunca se devuelven en caso de fallo de política.
• Fallos de orquestación asíncrona: Los trabajos de orquestación pasan a DLQ y son reproducibles; una API de estado de trabajo permite a los clientes sondear o recibir devoluciones de llamadas.
• Estrategias de reserva: Si la resolución de identidad falla, devuelva un error determinista y opcionalmente una solución sugerida (por ejemplo, requerir externalId).

Consideraciones de diseño idempotentes

• Clave de impotencia: Los clientes proporcionan una clave de idempotencia (UUID + espacio de nombres de cliente) para acciones de mutación.
• Claves deterministas: Utilice claves compuestas (UnifiedIndividualId + ActionType + TimestampWindow) para detectar duplicados.
• Reintentos seguros: Diseñe acciones para ser tolerante a los efectos secundarios o para realizar alteraciones en vez de inserciones ciegas.
• Protección de reproducción: Persista en las claves de idempotencia procesadas y tléelas después del plazo comercial para evitar repeticiones.
• Apatridia: Mantenga las acciones síncronas sin estado donde sea posible; persista el estado mínimo para flujos de trabajo asíncronos.

Consideraciones de seguridad

• Autenticación: OAuth 2.0 (portador JWT o mTLS para cuentas de servicio); tokens de corta duración y rotación de actualización.
• Autorización: Punto de decisión de política aplica el Control de acceso basado en atributos (CEDAR) y las comprobaciones de consentimiento por solicitud.
• Cifrado de transporte y almacenamiento: TLS 1,2+ en tránsito; AES-256 en reposo para cualquier fragmento en caché o registro de auditoría.
• Privilegio menor: Clientes de API con un ámbito mínimo de permisos; funciones separadas para lectura frente a escritura frente a orquestación.
• Minimización de datos: Devuelva solo atributos solicitados y consentidos; aplique enmascaramiento dinámico para PII/PHI.
• Controles de red: Opcionalmente, requiera llamadas desde redes privadas (Private Connect, listas de admisión de IP) para acciones de alto riesgo.
• Auditoría y supervisión: Registre metadatos de solicitudes, decisiones de políticas, identidad del solicitante y hashs de respuesta en Trust Layer y SIEM.

Barras laterales

Oportunidad

• Diseñado para latencias medias en el intervalo de subsegundo a bajo-segundo único para acciones síncronas.
• Las memorias caché periféricas (TTL corto) y las perspectivas precalculadas reducen los recorridos de ida y vuelta.
• Las rutas asíncronas proporcionan confirmación casi instantánea con procesamiento en segundo plano para tareas pesadas.

Volúmenes de datos

• Optimizado para interacciones de un solo registro o pequeños lotes (1 a 100 registros).
• No pensado para exportaciones masivas: utilice la activación por lotes para grandes volúmenes.
• El alto rendimiento utiliza la reutilización de combinación/conexión y colas de orquestación paralelas.

Gestión de estado

• Modelo de solicitud sin estado para llamadas síncronas; el estado de acción mínimo persistió para subvenciones/transacciones.
• Invalidación de caché dirigida por eventos de cambio: asegúrese de que los TTL y las señales de invalidación mantienen las caché actualizadas.
• Los trabajos de orquestación mantienen un estado duradero (jobId, status, reintentos) almacenado en Trust Layer.

Escenarios de integración complejos

• Asistente de agente: Búsqueda de perfil en tiempo real + propensión calculada devuelta a la consola de servicio en subsegundo para agentes.
• POS / Edge Devices: SDK local + Acción de datos ocasional para validar promociones o estado de fidelidad.
• Flujos híbridos: Sincronice la acción de datos para la decisión + orquestación asíncrona para actualizar sistemas descendentes y desencadenar campañas.
• Middleware externo: Las pasarelas de MuleSoft o API pueden mediar en la autenticación, enriquecer el contexto y aplicar comprobaciones de políticas adicionales.

Ejemplo

Una aplicación móvil minorista determina si mostrar un cupón instantáneo personalizado cuando un comprador toca Checkout invocando la acción de datos de aptitud de oferta con el contexto de correo electrónico y carrito del comprador. La solicitud es validada por la pasarela de API y reenviada al Servicio de acción de datos, que resuelve el correo electrónico a un Id. de particular unificado utilizando una coincidencia de caché, verifica el consentimiento de marketing a través del PDP y evalúa la aptitud basándose en el valor de toda la vida del cliente y la recencia de compra reciente. Si el comprador califica, el servicio devuelve un token de cupón firmado y registra la decisión. Cuando la emisión de cupones requiere reserva de inventario, se desencadena una orquestación asíncrona para reservar inventario y notificar a los sistemas CRM. La aplicación muestra el cupón de inmediato, mientras que las actualizaciones descendentes se completan en segundo plano y Trust Layer captura un seguimiento de auditoría completo para la gobernanza y el cumplimiento.

• Conectores e integración
• SDK web y móvil
• Ingestión en tiempo real de subsegundos
• Bring Your Own Lake (Consulta de copia cero)
• Bring Your Own Lake (Archivo de copia cero)
• Gráficos de datos
• Activación: Implicación de MC
• Activación: Personalización de MC
• Activación: B2C Commerce
• Compartir datos (Copia cero)
• Activación: Almacenamiento de archivos
• Acciones de datos
• Acciones de datos de subsegundos en tiempo real
• Plataforma de activación externa