Mantener los datos consistentes

🌐 También en 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Français (Canada) · Deutsch (Schweiz)

Imagen generada con IA

Traducido con IA. Aún no revisado por la comunidad. Leer en inglés

Módulo 9 de 10 del capítulo Arquitectura de datos de Salesforce, capítulo 3 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: Propiedad y ciclo de vida · Siguiente: Diseña el modelo físico de Salesforce

La pregunta que responde este módulo: ¿Cómo mantengo los datos consistentes, y qué cuesta cada capa?

Todo el mundo quiere datos limpios. Nunca he entrado a una reunión de requisitos en la que alguien dijera: “Lo que de verdad nos gustaría son datos inconsistentes”. El desacuerdo viene después: ¿dónde hacemos cumplir las reglas? ¿En la pantalla? ¿Un campo obligatorio? ¿Una lista de selección, una regla de validación, una regla de duplicados, un flujo, Apex? Todos ayudan. No son intercambiables, y cada capa tiene un costo.

Mi regla general es llevar la regla tan abajo como razonablemente puedas. Si un valor solo puede ser una de cinco cosas, no dejes que la gente escriba cualquier cosa y luego lo limpies con automatización. Si dos registros nunca deben compartir un identificador, no confíes en que alguien lo detecte en un informe. Si una regla tiene que cumplirse venga el registro de una pantalla, una API, una integración, una carga de datos o un agente, no la hagas cumplir solo en la interfaz. Cuanto más cerca de los datos está la regla, más difícil es esquivarla. Lo llamo la escalera de la consistencia.

Peldaño uno: el tipo de campo y el vocabulario

La primera regla de consistencia es la del módulo 6: elige el tipo correcto. Una fecha es Fecha, un momento es Fecha/hora, el dinero es Divisa. Eso es consistencia antes de que nadie escriba una regla.

Haz del estado de una entrega un campo de texto y tendrás Delivered, delivered, DELIVERED, Complete, Done y Dropped off, y alguien tendrá que averiguar si esos seis significan lo mismo. O define el vocabulario una vez: Entregada, un valor, un significado. Hazlo una lista de selección restringida para que rechace cualquier cosa que no esté en la lista, incluso a través de la API, y un conjunto de valores global cuando varios campos comparten la lista (el módulo 6 tiene los detalles).

Pero no uses una lista de selección solo para impedir que la gente escriba. ¿Es de verdad un valor, u otra entidad? Nueve centros de distribución, cada uno con un nombre, pueden parecer una lista de selección; nueve con direcciones, gerentes, capacidad y camiones son registros. La regla debería reforzar el modelo, no compensar uno malo. Y si de verdad es un vocabulario controlado, contrólalo en el campo. No permitas el caos para luego construir un flujo que convierta AZ, Arizona, Ariz y zona de Phoenix en el valor que querías desde el principio.

Peldaño dos: obligatorio y único

Obligatorio y Único son atractivos porque son simples: marcas la casilla, problema resuelto. A veces. Si cada camión tiene un número de flota desde el día en que se crea, y no hay dos camiones que compartan uno, las dos casillas expresan reglas de negocio reales. Eso es consistencia fuerte.

Pero una vez que la plataforma hace cumplir una regla, no le importa que tu proceso tenga una excepción el martes por la tarde. Uso este ejemplo en clase desde hace años. Un objeto lleva tiempo existiendo, con muchísimos registros. Alguien agrega un campo y marca Obligatorio. Prueba a crear un registro: funciona de maravilla. Luego, el sábado por la noche, despliegue, se ejecutan las pruebas y una clase de prueba antigua crea el objeto sin el campo nuevo. Pum. O alguien edita un registro antiguo de antes de que existiera el campo. O la integración envía la misma carga que lleva cinco años enviando. Pum. “Pero si no cambiamos ese campo”. A la plataforma no le importa: cambiaste el contrato de lo que es un registro válido. Una regla nueva no solo afecta a los datos nuevos; cambia lo que puedes hacer con los datos antiguos.

Peldaño tres: reglas de validación

Las reglas de validación nos permiten decir cosas mucho más ricas. Si el estado es Entregada, la hora real de entrega tiene que estar completada. Si la parada es una instalación, la lista de verificación tiene que estar completa antes de poder cerrar la parada. Se ejecutan cuando se guarda el registro, así que protegen el registro tanto si se guardó desde una página como desde la API, una carga de datos, una integración o un agente. Esa es la idea. Si la regla tiene que proteger el registro, ponla donde la encuentre cada escritura.

También tienen dientes. Esa es su fuerza y su costo.

El problema de los registros antiguos

Aquí es donde se pone feo. Tienes un millón de registros y hoy agregas una regla: la hora de entrega no puede ser anterior a la salida de la ruta. Sensato. Pero veinte mil registros antiguos la incumplen, gracias a una migración de hace siete años. Un usuario abre uno de ellos y cambia el número de teléfono. Guardar. Salta la regla. “Cambié un número de teléfono. ¿Por qué me hablas de una hora de entrega de 2019?”. Pregunta justa.

Así que una regla de validación no solo debería decir qué tiene que ser cierto. Debería decir cuándo hacerlo cumplir. Funciones como ISNEW() e ISCHANGED() te permiten limitar una regla a los registros nuevos, o a los guardados en los que realmente cambian los campos relevantes (Validation Rule Considerations (opens in a new tab), en inglés).

Pero un registro no solo cambia cuando una persona lo edita, y muchas de las razones están fuera de tu control. La integración actualiza el estado durante la noche. Un flujo estampa una fecha. Un gerente reasigna un territorio y el propietario cambia en diez mil registros. Alguien edita un artículo de entrega, el resumen acumulativo de la entrega se recalcula y eso guarda la entrega, así que la regla de validación de la entrega salta para un usuario que nunca la tocó (Roll-Up Summary Field (opens in a new tab), en inglés, advierte que los errores de validación pueden aparecer en el detalle o en el principal). Cada uno de esos guardados se encuentra con tu regla nueva. Así que, para cada regla nueva, pregunta: ¿debería aplicarse esta regla a ese guardado?

Estas son las opciones, y las vas tejiendo dentro de la regla:

• Siempre, en cada guardado. Correcto cuando la regla de verdad trata del registro y los datos antiguos la cumplen. Pero ten claro lo que significa “cada guardado”: un trabajo por lotes que solo cambia el propietario, o cualquier edición pequeña de cualquier campo del registro, también tiene que cumplirla.
• Solo para registros nuevos, con ISNEW(). La regla revisa el registro una vez, cuando se crea, y nunca más. El pasado se queda como estaba, pero el futuro también: una edición posterior puede hacer que un registro nuevo incumpla la regla y nadie lo va a impedir. Si eso importa, combínala con la siguiente.
• Solo cuando cambian los campos de los que trata, con ISCHANGED(). Editar el número de teléfono no despierta la regla de la hora de entrega.
• No para ciertos escritores. Un permiso personalizado, revisado en la fórmula como $Permission, deja pasar al usuario de integración o a una migración de datos mientras las personas siguen cumpliendo la regla (How to Reference a Custom Permission in a Validation Rule (opens in a new tab), en inglés). Dalo a propósito y a pocos.
• De una fecha en adelante, comparando CreatedDate con el día en que la regla entró en vigor, cuando “nuevo” significa “desde que empezamos a hacer cumplir esto”. A diferencia de ISNEW(), sigue revisando esos registros en cada guardado posterior, así que vale la misma advertencia: un cambio menor, como una actualización de propietario por lotes, puede fallar en un registro que se ha desviado.

¿Vas a agregar una regla a registros que ya tienes? Piensa bien en las consecuencias antes de activarla. Cada registro existente tiene que cumplirla ahora en su próximo guardado, y ese guardado puede venir de donde no lo esperabas: una integración nocturna, un cambio de propietario por lotes, un resumen acumulativo, una actualización masiva desde una vista de lista. ¿Cuáles de ellos se toparán con ella, y qué le pasa a ese trabajo cuando falla un registro? La sección Antes de activarla tiene la secuencia que uso.

No reescribas el historial para dejar contenta a la regla

¿Y los veinte mil registros antiguos? Si los datos están mal y conoces los valores correctos, corrígelos. Pero he visto otro tipo de “arreglo”: nadie conoce la verdad histórica, solo necesitan que los registros pasen, así que los actualizan con valores que satisfacen la regla de hoy. No me gusta. Actualizar los registros antiguos para que cumplan cambia LastModifiedDate y destruye información histórica clave, e inventar valores significa fingir que sabemos algo del pasado que no sabemos. Dale a la regla una excepción para los registros anteriores a ella en lugar de reescribir el historial. Puede ser feo, pero es honesto.

La validación en la interfaz no es validación de datos

Haz un campo obligatorio en un formato de página y los usuarios no podrán guardar sin él. Luego la integración nocturna inserta 50,000 registros. ¿Usó tu página? No. Tampoco la carga masiva, el cliente de la API ni el agente. Un requisito de interfaz protege esa pantalla, no los datos. La validación de campos en los formularios dinámicos se puede esquivar de la misma manera. Así que pregunta: ¿por dónde pueden entrar estos datos? Lightning, el portal, el celular, la integración, la API, una carga masiva, Flow, Apex, un agente. Cuantas más puertas haya, menos confío en una regla que solo vigila una de ellas.

Peldaño cuatro: reglas de duplicados

Ahora pasamos de la consistencia dentro de un registro a la consistencia entre registros. Acme Corporation, ACME Corp, Acme Inc.: ¿cuatro clientes o uno? Ninguna regla de campo puede responder eso. Las reglas de coincidencia definen cómo se comparan los registros; las reglas de duplicados deciden qué pasa cuando se encuentra un probable duplicado: permitir con una advertencia, bloquear o informar. Puedes tener hasta cinco reglas de duplicados activas por objeto y hasta tres reglas de coincidencia en cada una, y las claves de coincidencia limitan cada comparación a los 100 duplicados más probables (Things to Know About Duplicate Rules (opens in a new tab), en inglés).

Su costo es la fricción. Si cada cuenta que crea un representante dice Se ha encontrado un posible duplicado, a veces es exactamente lo que quieres, y a veces la gente aprende a hacer clic sin leer. Los registros legítimos pueden parecerse, y una integración puede necesitar un comportamiento distinto del de una persona. Y la advertencia es la propia de Salesforce: su alerta y su lista de posibles duplicados pueden no encajar en una pantalla personalizada que hayas construido, y cuando el guardado es sin interfaz (headless), una integración, una carga de datos, un agente, no hay ninguna pantalla en la que mostrarla. Así que decide cómo aparece un duplicado en cada camino: una advertencia para una persona, un guardado bloqueado y un error para la API, o la opción Informar y los conjuntos de registros duplicados para que alguien los revise después. La buena arquitectura no es el máximo control; es el control correcto.

Y comprueba qué puertas protege de verdad una regla de duplicados (Things to Know About Duplicate Rules (opens in a new tab), en inglés). A través de la API y de las herramientas de importación de datos, nadie ve la advertencia: una regla configurada para alertar simplemente bloquea el guardado. Algunos caminos se saltan las reglas por completo: Creación rápida, el botón Recuperar, una fusión manual, los registros agregados por Lightning Sync o Einstein Activity Capture. Y los registros guardados en el mismo momento no se comparan entre sí, solo con los registros que ya están en Salesforce. Carga un archivo con el mismo cliente dos veces, y las dos filas pueden pasar. Una regla de duplicados es una buena red. No es un candado en la puerta.

Conocimiento para el examen. Las reglas de duplicados no comparan entre sí los registros guardados en el mismo momento, solo con los registros que ya están en Salesforce. A través de la API y las herramientas de importación no hay alerta: un duplicado que la regla detecta simplemente no se guarda. Y un guardado y todo lo que desencadena se ejecutan como una sola transacción: si alguna parte falla, todo se revierte.

Un límite. Las reglas de duplicados mantienen limpia una organización. No resuelven la identidad a nivel de empresa. Si Salesforce tiene Acme Corporation, el ERP tiene ACME-10382 y facturación tiene el cliente 77193, una regla de duplicados no puede decirte que son la misma empresa. Eso son datos maestros, capítulo 6.

Peldaño cinco: automatización

Algunas reglas son demasiado complejas para los peldaños inferiores: necesitan registros relacionados, otro sistema, registros dependientes, un proceso de varios pasos. Eso es Flow, Apex y, a veces, lógica de integración. (No Workflow Rules ni Process Builder; ya no tienen soporte.) La automatización es potente y más cara: más piezas móviles, más pruebas, más manejo de errores, más formas de que una automatización tropiece con otra. Y el código trae sus propios errores. Si el tipo de campo puede hacerlo cumplir, no escribo Apex. Si una regla de validación lo dice con claridad, no construyo un flujo solo porque Flow está ahí. No resuelvas un problema de campo con un motor de procesos.

Todo o nada: cuando los registros cambian juntos

Hasta aquí, cada peldaño protege un guardado. Pero los registros cambian juntos: una entrega y sus artículos, un pedido y sus líneas, un flujo que actualiza tres objetos. Aquí la plataforma te da una garantía fuerte. Un guardado y todo lo que desencadena, los desencadenadores, los flujos, las clases que llaman, se ejecutan como una sola transacción: si alguna parte falla, todo se revierte y no se confirma nada (Apex Transactions (opens in a new tab), en inglés). No te queda media entrega.

El trabajo masivo es la excepción que tú eliges. Una carga de datos o un método Database de Apex puede permitir el éxito parcial: los registros buenos se guardan, los malos vuelven con sus errores, y alguien tiene que ocuparse de ellos (DML Statements vs. Database Class Methods (opens in a new tab), en inglés). Eso suele ser lo correcto para una carga de un millón de filas, pero entonces la consistencia es un proceso: ¿quién lee el archivo de errores, y qué pasa con los registros que fallaron?

Y luego está el momento. Dos guardados en el mismo instante pueden pasar los dos una comprobación que cada uno, por separado, no pasaría. Un flujo que busca un pedido existente y luego crea uno puede dejar pasar dos, y acabamos de ver que las reglas de duplicados no comparan los registros guardados al mismo tiempo. Un campo marcado como Único, o un ID externo, lo comprueba la plataforma en cada guardado, así que solo uno de ellos gana. Es una razón más para llevar la unicidad hasta el campo. Los bloqueos, la contención y los reintentos son un tema aparte; el capítulo 11, Transacciones, concurrencia y confiabilidad, lo trata a fondo.

Lleva la regla hacia abajo, hasta que deje de pertenecer ahí

“Tan abajo como razonablemente puedas” no significa “siempre lo más abajo”. Si un campo solo es obligatorio cuando una oportunidad llega a cierta etapa, hacerlo obligatorio en el esquema es un error; la regla es condicional, así que una regla de validación es el peldaño correcto. Si un duplicado debería advertir a una persona pero una integración aprobada tiene su propia conciliación, diseña para los dos caminos. El objetivo: la capa más baja que representa correctamente la regla de negocio.

Cada capa tiene un costo

Click to enlarge

Esta es la compensación que quiero que veas. Los tipos de campo y los valores controlados son simples y fuertes, pero solo para lo que un campo puede expresar. Obligatorio y Único son contundentes: una vez activados, cada escritura tiene que cumplirlos. Las reglas de validación expresan condiciones más ricas, pero pueden bloquear ediciones de registros antiguos y sorprender a un despliegue. Las reglas de duplicados protegen entre registros, pero agregan fricción para los usuarios y las integraciones. La automatización resuelve cualquier cosa, pero te obliga a hacerte cargo de la orquestación, los errores, las pruebas y el rendimiento. No hay ninguna capa gratis. Elige la capa de cada regla sabiendo cómo falla.

Antes de activarla

Agregar una regla a una organización existente es un despliegue, no una casilla. ¿Cuántos registros la incumplen hoy, y por qué? ¿Están realmente mal? ¿Podemos conocer el valor correcto? ¿La regla es cierta históricamente, o solo de aquí en adelante? ¿Qué integraciones, pruebas y automatizaciones se toparán con ella? Una buena secuencia: mide, limpia lo que puedas demostrar que está mal, delimita la regla, agrega una excepción deliberada para el historial legítimo, prueba cada camino de escritura y luego hazla cumplir. Medir y limpiar son disciplinas propias, el perfilado, la estandarización, el monitoreo, la custodia de los datos, y el capítulo 5, Calidad y gobierno de datos, las cubre. Mucho mejor que marcar una casilla el viernes y descubrir las consecuencias el sábado por la noche.

Más allá del examen: lo que cambia la IA. Un agente puede crear registros más rápido que cualquier persona, y registros malos igual de rápido. “Los usuarios saben que eso no se hace” no es una protección cuando el usuario es un agente. Pon las reglas importantes en la capa de datos, donde las encuentre cada escritor, para que el agente no tenga que recordar las reglas no escritas de la empresa.

Steve Trucking: protege la entrega

Toma una entrega. Su estado viene de un solo vocabulario: una lista de selección, restringida. La referencia del pedido del socio minorista tiene que ser única por socio, así que es un ID externo, marcado como único, usado para hacer upsert del manifiesto. La hora real de entrega es obligatoria una vez que el estado es Entregada: una regla de validación, limitada a ese cambio. Una parada de instalación no se puede cerrar hasta que su lista de verificación esté completa y se hayan tomado las fotos obligatorias (para un lavavajillas, la toma de agua, el desagüe y la nivelación): una regla de validación, o automatización si tiene que comprobar las fotos guardadas fuera de la plataforma. El mismo pedido que llega dos veces por un manifiesto reenviado lo detecta el ID externo; dos pedidos distintos que se parecen son una cuestión de coincidencia.

Fíjate en que no dije “ponlo todo en un flujo”. Cada regla está en su propio peldaño. Para cada regla, pregunta: ¿cuál es la capa más baja que la hace cumplir correctamente en cada camino de escritura que importa?

Lo que decide aquí un arquitecto

• En qué peldaño va cada regla: tipo de campo, vocabulario controlado, obligatorio o único, regla de validación, regla de duplicados o automatización.
• Qué caminos de escritura hay que proteger: interfaz, portal, celular, integraciones, cargas masivas, API, automatización y agentes.
• Si una regla nueva aplica a los registros históricos, o se limita a los datos nuevos y cambiados con una excepción para el pasado.
• Si los datos malos existentes pueden corregirse a partir de evidencia, en lugar de reescribirse para que pasen.
• Cuánta fricción, complejidad y mantenimiento vale una regla.

Los datos limpios no vienen de pedirle a la gente que ingrese buenos datos. Vienen de una arquitectura que hace fácil lo correcto, difícil lo incorrecto, y difíciles de esquivar las reglas importantes. A continuación, juntamos el capítulo en una porción de Steve Trucking.

Explora

• Ayuda de Salesforce, How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (opens in a new tab) y Roll-Up Summary Field (opens in a new tab) (en inglés), consultado el 2026-10-13.
• Ayuda de Salesforce, Picklist Limitations (opens in a new tab) (en inglés), consultado el 2026-10-02.
• Ayuda de Salesforce, Validation Rule Considerations (opens in a new tab) (en inglés), consultado el 2026-10-02.
• Ayuda de Salesforce, Things to Know About Duplicate Rules (opens in a new tab) (en inglés), consultado el 2026-10-13: los límites, los caminos en los que las reglas no se ejecutan, los guardados por API e importación bloqueados sin alerta, los guardados simultáneos que no se comparan.
• Apex Developer Guide, Apex Transactions (opens in a new tab) y DML Statements vs. Database Class Methods (opens in a new tab) (en inglés), consultado el 2026-10-13: una transacción se revierte como unidad; los métodos de Database pueden permitir el éxito parcial.
• Ayuda de Salesforce, Workflow Rules & Process Builder End of Support (opens in a new tab) (en inglés), consultado el 2026-10-02.