Los campos también son arquitectura

🌐 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 6 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: Elige el objeto correcto · Siguiente: Las relaciones tienen consecuencias

La pregunta que responde este módulo: ¿Cómo debería representar físicamente Salesforce cada dato?

Crear un campo lleva más o menos un minuto. Nuevo campo, eliges un tipo, le pones nombre, Siguiente, Siguiente, Guardar. Precisamente por eso los campos no se tratan como arquitectura.

Entra en una organización que lleva diez años funcionando y abre la cuenta. Quinientos campos. Status2__c, Legacy_Status__c, Old_Status__c, Status_New__c. Tres números de cliente distintos. Una casilla que nadie va a eliminar porque nadie sabe qué integración la sigue usando. Crear el campo llevó un minuto. Vivir con él lleva años. Así que la idea de este módulo es sencilla: un campo es una decisión de arquitectura. No siempre una grande, pero cada campo codifica algo sobre el significado, el comportamiento, la identidad o la calidad de los datos, y como los objetos, los campos son fáciles de agregar y sorprendentemente difíciles de quitar.

¿Qué significan realmente estos datos?

En el capítulo 2 les dimos atributos a nuestras entidades: una entrega tiene una franja programada, un camión tiene un VIN. Ahora los implementamos, y aquí es donde la gente salta directo a “campo de texto”. Espera. Antes del tipo, quiero saber qué significan los datos. ¿Es un número, o un identificador que casualmente tiene dígitos? ¿Una fecha, o un momento en el tiempo? ¿Texto libre, o uno de un conjunto aprobado? ¿Lo ingresa una persona, o es propiedad de otro sistema? ¿Puede cambiar? ¿Debe ser único? ¿Puede faltar? ¿Debería guardarse siquiera, o calcularse? No son preguntas de Setup. Son preguntas de arquitectura de datos, y el tipo de campo viene después de responderlas.

Un número no siempre es un número

Steve Trucking le da a cada camión un número de flota, digamos 001247. ¿Campo numérico? Probablemente no. ¿Sumamos números de flota? ¿El camión 1247 menos el camión 1246 es un camión? Es un identificador que casualmente contiene dígitos, y un campo numérico hasta quitaría los ceros a la izquierda. Lo mismo vale para los códigos postales, los códigos de producto, los números de cuenta y los números de seguimiento. Cómo se ve el valor no te dice qué significa. Elige el tipo por el comportamiento que necesitas, no por cómo se ven los datos de ejemplo.

¿Necesita una persona identificarlo?

Cada objeto personalizado tiene un campo Name, y la primera decisión es texto o numeración automática. Pregunto: ¿necesita una persona identificar esta cosa? La gente conoce a un socio minorista por su nombre y a un camión por su número de flota. Pero ¿un manifiesto que el sistema genera cada noche? Nadie debería estar escribiendo “Manifiesto 10-02 Número 3” porque Salesforce exigía un Name. Dale una numeración automática. Solo no confundas ese Name generado con la identidad del registro: la numeración automática ayuda a los usuarios, el ID de Salesforce identifica el registro, y la propia referencia del manifiesto del socio minorista puede identificar lo mismo entre sistemas. Tres trabajos distintos.

La pantalla de detalles

Eliges un tipo, haces clic en Siguiente y Setup te pide los detalles. Esta es la pantalla donde se toman de verdad la mayoría de las decisiones de este módulo, normalmente con prisa.

Nuevo campo personalizado, paso 2: los detalles (captura de pantalla, 2026-10-12). Tamaño completo

Dos casillas se parecen y hacen trabajos distintos. Descripción es para las personas que mantienen la organización, y ahora también para las herramientas de IA que la leen: qué significa el campo, quién es su dueño, de dónde viene. Texto de ayuda es para el usuario que está en la pantalla: qué escribir aquí. Llena las dos. Luego vienen Obligatorio, Único e ID externo, y cada una merece su propia sección. Debajo, Valor predeterminado puede ser una fórmula, así que un registro nuevo puede empezar con un valor sensato en lugar de en blanco.

Obligatorio es una decisión más grande de lo que parece

Hay una pequeña casilla en el asistente de campos llamada Obligatorio, y como vimos en el capítulo 1, puede ser una bomba de tiempo. Tienes un objeto desde hace cinco años y dos millones de registros, y ahora alguien decide que un campo nuevo debe tener siempre un valor. ¿Qué pasa con los dos millones de registros anteriores? ¿Con las integraciones que no lo envían? ¿Con la automatización que crea el registro antes de que se conozca el valor? ¿Con el proceso en el que el valor solo aparece tres pasos después?

“Obligatorio” suena a decisión de calidad de datos, y a veces lo es. Pero cuándo se conoce un valor es parte del proceso de negocio. Así que no marques Obligatorio porque alguien dice “siempre queremos eso”. Pregunta cuándo se conoce, quién lo aporta y qué pasa cuando no está. Lo pondremos en la escalera completa de consistencia en el módulo 7.

Único también significa algo

Si marco un campo como único, estoy haciendo una afirmación sobre el negocio: no “normalmente no se repite”, sino “dos registros nunca pueden tener este valor”. Es fuerte. Y la pantalla te obliga a decidir una cosa más: ¿“ABC” y “abc” son el mismo valor o valores distintos? Sin distinguir mayúsculas y minúsculas es el valor predeterminado más seguro para todo lo que escribe una persona. La regla de las claves del capítulo 2, única, inmutable, sin significado, nunca datos personales (PII), aplica aquí. Si alguien me dice que el correo del empleado es único, empiezo a preguntar: ¿puede cambiar, alguien puede irse y volver, se pueden reutilizar las direcciones, qué pasa después de una adquisición? El correo puede ser útil, incluso único hoy. Eso no lo convierte en una buena identidad.

ID externos: identidad a través de la frontera

Aquí es donde los ID externos se ganan el sueldo. La pantalla lo describe bien: el campo se convierte en “el identificador único de registro de un sistema externo”. El ERP tiene el cliente 873492; Salesforce tiene su propio ID de registro. Cuando el ERP envía una actualización, ¿cómo sabemos a qué registro pertenece? Marca un campo como ID externo y una integración puede hacer upsert sobre él: crear el registro si no existe, actualizarlo si existe (Upsert a Record Using an External ID (opens in a new tab), en inglés). Y cuando cargas registros hijos, puedes apuntar al padre por su ID externo en lugar de consultar primero el ID de Salesforce. Me gusta decir que dejas que Salesforce haga la búsqueda por ti. Muy potente.

Fíjate en que el número del ERP no se convierte en la identidad del registro de Salesforce. Es un atributo, y un registro puede llevar varios: un ID de cliente del ERP, un ID heredado, un ID del socio. Está bien. Una entidad de negocio puede ser conocida de forma distinta por varios sistemas. La pregunta de arquitectura es qué sistema es dueño de cada identificador y qué promesa hace: márcalo como único solo si el negocio lo garantiza de verdad.

Tipo de campo por tipo de campo

Ahora, los tipos en sí. Abre Nuevo campo en cualquier objeto y Setup te muestra la lista completa, agrupada tal como la voy a recorrer: los campos que Salesforce calcula por ti, los campos de relación y luego los tipos de datos.

Setup, Nuevo campo personalizado, paso 1: los tipos de datos (captura de pantalla, 2026-10-12). Tamaño completo

Aquí está la lista completa de un vistazo, con lo único que quiero que recuerdes de cada uno.

Grupo	Tipo	Recuerda
Calculados	Numeración automática	Hasta 30 caracteres, 20 de ellos de prefijo o sufijo; una etiqueta para las personas, no la identidad del registro
	Fórmula	Se calcula al leerse, no se guarda; 3,900 caracteres
	Resumen acumulativo	Recuento, suma, mínimo o máximo de los detalles; solo principal-detalle
Relaciones	Búsqueda, Principal-detalle, Búsqueda externa	Módulo 7
Datos	Casilla de verificación	Verdadero o falso, con un valor predeterminado que tú eliges; null todavía puede aparecer en los flujos
	Número, Porcentaje, Divisa	Reglas de redondeo; se pierden los ceros a la izquierda; 15 decimales
	Fecha, Fecha/hora, Hora	Un día, un momento o una hora del día; los momentos se guardan en UTC
	Correo electrónico, Teléfono, URL	Con formato y validados al guardar: 80, 40 y 255 caracteres
	Geolocalización, Dirección	Campos compuestos que cuestan más de un campo: 3 y 9
	Lista de selección, selección múltiple	Un vocabulario controlado, propiedad de un administrador
	Texto, Área de texto, largo, enriquecido, cifrado	Hasta 255 en el registro e indexable; por encima, sin índice ni filtrado

Los campos que calcula Salesforce

La numeración automática asigna el siguiente número de una secuencia a cada registro nuevo, en el formato que tú definas, como T-{000000}. Úsala cuando una persona necesita un identificador cómodo y nadie debería tener que inventárselo. El valor completo tiene hasta 30 caracteres, y 20 de ellos están reservados para el prefijo o el sufijo. Solo recuerda lo del capítulo 2: es una etiqueta para las personas, no la identidad del registro, y los números no siempre son estrictamente consecutivos.

Los campos de fórmula calculan un valor a partir de otros campos. Son potentes, y se calculan cuando se lee el registro, no cuando se guarda, así que no hay nada guardado que pueda quedar desactualizado. Tú eliges qué devuelve la fórmula: una casilla de verificación, divisa, fecha, fecha/hora, número, porcentaje, texto u hora.

Nuevo campo personalizado, fórmula: elegir el tipo de valor devuelto (captura de pantalla, 2026-10-12). Tamaño completo

Luego escribes la fórmula en sí, con campos, operadores y funciones, y compruebas su sintaxis. Fíjate en el botón Use Formula Assistant: la IA de Salesforce ahora te ayuda a escribir la fórmula. Úsala, y luego lee lo que escribió. La fórmula es tuya, no del asistente.

El editor de fórmulas, con el Formula Assistant (captura de pantalla, 2026-10-12). Tamaño completo Una fórmula puede tener hasta 3,900 caracteres, y no puede superar los 15,000 bytes al guardarse o compilarse; una fórmula larga se puede dividir en varios campos de fórmula que se referencian entre sí. Las áreas de texto largo, los campos cifrados y los campos Descripción no se pueden usar en ellas.

Los campos de resumen acumulativo están en el principal y cuentan, suman o toman el mínimo o el máximo de sus registros de detalle. Solo funcionan a través de una relación principal-detalle, que es una de las razones más importantes para elegir principal-detalle. Volveremos a ellos, y a sus límites, en el módulo 7.

¿Guardado o derivado?

¿Necesitamos guardar este valor siquiera? Si tengo la cantidad y el precio unitario, ¿alguien, o alguna automatización, necesita mantener un total? Quizá una fórmula debería derivarlo: una sola fuente para el cálculo, que se recalcula al leerse, así que cambias la cantidad y la respuesta la sigue. Las fórmulas tienen sus propios límites (tamaño al guardar y longitud mostrada; Formula Field Limits and Restrictions (opens in a new tab), en inglés), y las complejas se vuelven difíciles de mantener.

Pero a veces el negocio no quiere la respuesta de hoy. Quiere la respuesta tal como era. Si la regla de descuento cambia el año que viene, ¿la factura del año pasado debería mostrar de repente otro importe? Claro que no. Así que la pregunta no es “¿puede Salesforce calcular esto?”. Es “¿esto es un cálculo actual o un hecho histórico?”. Los hechos históricos se guardan.

Los campos de relación

Las relaciones de búsqueda, principal-detalle y búsqueda externa también son campos, y es ahí donde las líneas de tu modelo se vuelven reales. La búsqueda es el vínculo flojo; principal-detalle ata la vida, la propiedad y la seguridad del hijo al padre; la búsqueda externa llega a un objeto externo del módulo 4, emparejando por su ID externo. Elegir entre ellas es una decisión lo bastante grande como para tener su propio módulo.

Casilla de verificación

Una casilla de verificación es el campo más simple que existe: verdadero o falso, marcada o sin marcar. Es perfecta para un hecho de sí o no sobre el registro: Está activo, Requiere instalación, Firmado. Cuando creas una, Salesforce te obliga a elegir su valor predeterminado, marcada o sin marcar, y es una decisión real: es con lo que empieza cada registro nuevo, incluidos los registros que crea una integración sin enviar el campo. Los informes y las vistas de lista la filtran como True y False; las herramientas de importación y la exportación semanal la muestran como 1 y 0.

Una trampa que conviene conocer. El campo del registro tiene dos valores, pero la automatización a su alrededor puede tener un tercero. En un flujo, una variable de casilla de verificación a la que nunca se le asignó valor es null, no falso, y guardarla en un registro falla (Trailblazer Community (opens in a new tab), en inglés; ve también el problema conocido de Salesforce W-11208535 (opens in a new tab)). Elige un valor predeterminado sensato, y haz que tus flujos y tu código traten el null a propósito.

Número, porcentaje y divisa

Número guarda un número real y quita los ceros a la izquierda, que es justo por lo que un número de flota como 001247 no es un Número. Salesforce redondea los campos numéricos alejándose del cero en la mitad: 12.345 se convierte en 12.35, y −12.345 en −12.35. Y en los campos de combinación, redondea según la configuración regional del usuario, no según los decimales que definiste en el campo.

Porcentaje guarda un decimal y muestra un porcentaje: ingresas 0.10 y ves 10%. Los valores pierden precisión después de 15 decimales.

Divisa tiene formato de dinero, y en una organización con varias divisas lleva su código de divisa y puede usar tipos de cambio; con la gestión avanzada de divisas (opens in a new tab) (en inglés), las oportunidades pueden usar tipos de cambio con fecha, el tipo del periodo en el que se cerró el acuerdo. Solo las oportunidades y lo que las rodea (productos, programas, divisiones y sus informes) usan tipos con fecha; los campos de divisa de otros objetos mantienen el único tipo estático. Cuidado con el redondeo: sin decimales, Salesforce simplemente trunca (23.5 se convierte en 23); con uno o más, redondea alejándose del cero en la mitad.

Fecha, fecha/hora y hora

Tres tipos, tres significados distintos. Una Fecha es un día: un contrato vence en una fecha. Una Fecha/hora es un momento: la entrega llegó a las 9:42 de esa mañana. Una Hora es una hora del día sin fecha alguna: la tienda abre a las 7:00, todos los días.

La trampa es el momento. Salesforce guarda los valores de fecha/hora en GMT (UTC). La hora que escribe un usuario se interpreta en su zona horaria, se convierte y se guarda; cuando alguien la lee, se vuelve a convertir a la zona horaria de quien la lee. La mayor parte del tiempo eso es exactamente lo que quieres. Pero este es el ejemplo que doy en clase: una coordinadora en Los Ángeles registra una entrega tarde el domingo por la noche, a las 10 p. m. hora del Pacífico. Por debajo, Salesforce guardó el lunes por la mañana, a las 5 a. m. GMT. Un informe agrupado por día en otra zona horaria, o una integración que lee el valor bruto, puede poner esa entrega del domingo en lunes. “El día en que pasó” depende del reloj de quién mires. Vigila las zonas horarias de los usuarios, y decide a cuál se refiere el negocio.

Y ten cuidado al compararlas. Por debajo, una fecha/hora es un número grande: Apex la lee como la cantidad de milisegundos desde el 1 de enero de 1970, 00:00:00 GMT (Datetime Class (opens in a new tab), en inglés). Es un momento preciso, no un día. Así que preguntar si dos fechas/horas son iguales (==) casi nunca hace lo que quieres: 9:42:00 y 9:42:01 no son iguales, y tampoco lo son “el lunes” y cualquier momento del lunes. En su lugar, pide un rango: en el inicio o después (>=) y en el final o antes (<=). “Todas las entregas del lunes” son todas las entregas >= lunes 00:00 y <= lunes 23:59:59, en la zona horaria que decidiste que el negocio quiere decir.

Y una curiosa: Salesforce no puede guardar cualquier fecha. Las fechas válidas van del 1 de enero de 1700 al 31 de diciembre de 4000, y Salesforce da el mismo rango para fechas y fechas/horas (Data Import Dates (opens in a new tab), en inglés). Incluso los extremos son momentos en GMT, así que para un usuario en la hora del Pacífico el primer valor válido es las 4 p. m. del 31 de diciembre de 1699. Puede que la fecha de fundación de tu sociedad histórica no quepa. Y el truco clásico de “sin fecha de fin”, el 31 de diciembre de 9999, se rechaza; si necesitas un marcador para un futuro lejano, tiene que ser en el año 4000 o antes.

Correo electrónico, teléfono y URL

Estos son los campos con formato, y hacen más que guardar caracteres. Correo electrónico admite hasta 80 caracteres y se valida que tenga un formato correcto; en contactos y prospectos, hacer clic en él inicia un correo a esa dirección. Teléfono admite hasta 40 caracteres, tiene formato de número de teléfono y se vuelve clic para marcar cuando la organización tiene un sistema telefónico conectado. URL admite hasta 255 caracteres y se abre como vínculo. Es la plataforma dándote comportamiento gratis, y por eso yo nunca guardaría un número de teléfono en un campo de texto simple.

Las integraciones también se validan. Un valor que no coincide con el formato del campo, como una dirección de correo mal formada, no pasa la validación, y se rechaza el registro completo, no solo ese campo. Así que cuando los datos del sistema de origen están sucios, límpialos antes de que lleguen, o planifica para los registros que no se van a cargar.

Geolocalización y dirección

Geolocalización guarda una latitud y una longitud. Por debajo, un campo llamado Location__c son en realidad dos valores que puedes leer y asignar por separado, Location__Latitude__s y Location__Longitude__s. Y puedes consultar sobre él: las funciones DISTANCE y GEOLOCATION de SOQL encuentran registros dentro de un radio, o los ordenan por lo lejos que están. “Todas las entregas abiertas a menos de 25 millas de este camión” es una sola consulta: WHERE DISTANCE(Location__c, GEOLOCATION(33.45, -112.07), 'mi') < 25 (Location-Based SOQL Queries (opens in a new tab), en inglés). Dirección guarda una dirección completa, calle, ciudad, estado o provincia, código postal y país, y los usuarios pueden buscar una dirección y que se llenen las partes.

Los dos son campos compuestos: un campo en la pantalla, varios por debajo. Y cuestan más de un campo frente al límite de tu objeto: una geolocalización cuenta como tres campos personalizados, y una dirección como nueve. En un objeto que ya está lleno, eso importa.

Lista de selección y selección múltiple

Una lista de selección controla lo que los usuarios pueden ingresar: un valor de una lista que tú defines. ¿Estado? Lista de selección, probablemente. Pero los valores son metadatos, y un administrador tiene que agregarlos o cambiarlos. Así que igual pregunto quién es dueño de los valores, con qué frecuencia cambian, si varios objetos necesitan la misma lista, si los valores llevan información propia y si otro sistema es dueño del vocabulario.

Dónde viven los valores también es una decisión. Cuando una lista se usa una sola vez, en un solo campo, deja los valores en el propio campo, en el objeto; es lo que Salesforce hace de forma predeterminada. Pero cuando el mismo conjunto de valores empieza a aparecer en varios lugares, una Región en la cuenta, en la entrega y en el almacén, promuévelo a un conjunto de valores global antes de que las copias se separen. Un conjunto de valores global mantiene una sola lista para todos ellos, hasta 1,000 valores, activos e inactivos combinados (Picklist Limitations (opens in a new tab), en inglés). La propia descripción de Setup dice por qué importa: el conjunto de valores “está restringido para que los usuarios no puedan agregar valores no aprobados mediante la API”. Una lista, un dueño, y ninguna integración colando una ortografía nueva.

Ese último punto es la diferencia entre restringida y no restringida. En una lista de selección restringida, solo se permiten los valores que definió un administrador, vengan de donde vengan: un usuario, una importación o una integración que envía cualquier otra cosa recibe un error, “bad value for restricted picklist field”, y el registro no se guarda. En una lista de selección no restringida, los usuarios siguen eligiendo de la lista en la pantalla, pero la API, las importaciones y la automatización pueden enviar cualquier valor, y Salesforce lo guarda y lo agrega como valor inactivo (Picklist Limitations (opens in a new tab); Create a Custom Picklist Field (opens in a new tab), en inglés). Así es como una organización termina con “Delivered”, “delivered” y “Dlvrd”. Los conjuntos de valores globales siempre son restringidos. Mi opción predeterminada es restringida; no restringida es una elección deliberada para cuando otro sistema es realmente dueño de los valores, y entonces alguien se encarga de limpiar los inactivos.

Setup, Conjuntos de valores de lista de selección: un conjunto de valores global nuevo (captura de pantalla, 2026-10-12). Tamaño completo

Una lista de selección múltiple deja que un usuario elija varios valores, guardados juntos separados por punto y coma. Cómoda en una pantalla, incómoda en todo lo demás: más difícil de filtrar, de usar en informes y de integrar, y no se puede usar en el filtro de un resumen acumulativo. Varios valores para un mismo registro suelen significar la lección del capítulo 2: hay un objeto hijo tratando de salir.

Una lista de selección también tiene un valor más que los que definiste: en blanco. Un registro puede quedarse sin nada seleccionado, y eso agarra desprevenida a la gente. En una fórmula o una regla de validación no puedes probar una lista de selección solo con ISBLANK; escribes ISBLANK(TEXT(Field__c)), o ISPICKVAL(Field__c, "") (Trailblazer Community (opens in a new tab), en inglés). Así que decide qué significa “sin valor” para cada lista de selección: ¿está permitido, y qué significa cuando pasa? Luego haz que tus fórmulas, reglas de validación y filtros lo manejen.

Y a veces un atributo es en realidad una entidad. Alguien pide una lista de selección de centros de distribución. Hay nueve. Fácil. Luego nos enteramos de que cada uno tiene una dirección, un gerente, un horario, una capacidad, una región y camiones. Eso no es una lista de selección; es una cosa. No conviertas una entidad en una lista de selección solo porque todavía no hay muchas. Se siente genial el primer año y terrible el quinto. (El módulo 5 del capítulo 2 tiene mis reglas prácticas sobre cuándo una lista se gana su propio objeto).

La familia del texto

Enseño el texto como dos tipos, y la línea entre ellos está en 255 caracteres.

Hasta 255: se guarda con el registro. Texto admite hasta 255 caracteres, y lo puedes usar casi en cualquier parte: en fórmulas, filtros, informes, vistas de lista, como campo único o ID externo, y se puede indexar. Área de texto también admite 255, en líneas separadas, como una nota corta.

Más de 255: se guarda por referencia. Área de texto (largo) admite hasta 131,072 caracteres, y Área de texto (enriquecido) admite lo mismo con formato, vínculos e imágenes. Me los imagino guardados aparte, con el registro guardando un puntero, y se comportan así: sin índice, así que no puedes hacerlos únicos ni ID externo; no puedes filtrar por ellos en una cláusula WHERE de SOQL (SOQL WHERE (opens in a new tab), en inglés); las fórmulas no pueden usarlos (Formula Field Limits and Restrictions (opens in a new tab), en inglés); y los informes muestran solo los primeros 254 caracteres de uno personalizado, y los filtros de informe buscan solo en los primeros 255 más o menos (Filter Restrictions for Text Area (Long) Fields (opens in a new tab), en inglés). Las imágenes que se suben a un campo de texto enriquecido pueden ser de hasta 1 MB cada una, y cuentan contra el almacenamiento de archivos, mientras que el texto cuenta contra el almacenamiento de datos (Rich Text Area Field Considerations (opens in a new tab), en inglés). Así que si alguien necesita buscar, ordenar, emparejar o hacer informes sobre el valor, mantenlo por debajo de 255 y mantenlo como campo de Texto.

Texto (cifrado) guarda hasta 175 caracteres en forma cifrada, usando Classic Encryption. Si tu organización usa Shield Platform Encryption, en su lugar cifras un campo de Texto normal, y muchos otros tipos también se pueden cifrar así.

Dale una descripción a cada campo

Mi estándar: cada campo lleva una descripción. Lo creo desde hace mucho tiempo, y en el tiempo de la IA importa más que nunca: cada herramienta y agente de IA que lee tu organización lee las descripciones para entender qué significa un campo. Una descripción vacía es una suposición esperando a ocurrir. ¿Qué significa Customer_Status__c? ¿Quién es su dueño? ¿De dónde viene? ¿Los usuarios pueden editarlo, o el ERP lo sobrescribe esta noche? En seis meses no me acordaré, y en tres años el administrador que mantenga la organización no lo sabrá a menos que se lo hayamos dicho. La etiqueta no es documentación, y el nombre de API tampoco.

En los objetos muy compartidos (cuenta, contacto, oportunidad) también uso prefijos de nombre para los campos especializados, de modo que su origen y su propósito se vean en el propio nombre: todo lo que es propiedad del ERP empieza con el mismo prefijo, por ejemplo. No busco nombres de API de doce palabras. Quiero que el modelo se explique solo.

Clasifica lo que importa: los campos de taxonomía

Salesforce le da a cada campo un conjunto de metadatos de clasificación. Los llamo los campos de taxonomía. Puedes registrar el dueño de los datos; el uso del campo (Active, DeprecateCandidate, Hidden); el nivel de confidencialidad de los datos (Public, Internal, Confidential, Restricted, MissionCritical); y la categorización de cumplimiento: PII, HIPAA, GDPR, PCI, CCPA y otras. Funcionan tanto en los campos estándar como en los personalizados (Data Classification Metadata Fields (opens in a new tab), en inglés).

¿Para qué molestarse? Porque los procesos pueden leerlos. Marca un campo como GDPR y un proceso puede encontrar cada campo GDPR de un registro y enmascararlo o eliminarlo. Y cuando la capa de confianza de Salesforce envía una instrucción a un modelo de lenguaje grande, puede usar exactamente esta clasificación para enmascarar los campos sensibles: cambia el nombre de una clienta, digamos “Maria Lopez”, por un marcador de posición a la salida, el modelo nunca ve el nombre, y el nombre se vuelve a poner en la respuesta a la entrada (Einstein Trust Layer (opens in a new tab), en inglés).

Una actualización. Salesforce documenta ahora que el enmascaramiento basado en patrones y en campos para los LLM está desactivado para los agentes: el enmascaramiento puede quitar el contexto que un agente necesita para responder (Data Masking Limitations in Agentforce (opens in a new tab), en inglés). La clasificación sigue impulsando el enmascaramiento en otras funciones de IA generativa, pero no cuentes con ella para mantener los datos personales lejos de un agente; eso es una decisión de acceso y de diseño (capítulo 12).

Mi posición: la clasificación es importante en momentos clave. No la conviertas en tres semanas rellenando cada casilla porque lo dijo el área de gobierno. Úsala donde importa: datos personales, datos financieros, datos regulados y campos en los que el negocio necesita un dueño con nombre. La idea es que la confidencialidad deje de ser un conocimiento en la cabeza de alguien y pase a formar parte del campo.

Más allá del examen: lo que cambia la IA. Una mala documentación de los campos antes castigaba al siguiente administrador. Ahora confunde a cada herramienta y agente de IA que lee el esquema: ¿Flag2__c es sensible, es la referencia, se sigue usando? La IA también crea campos más rápido que cualquier equipo, así que los nombres, las descripciones y la clasificación son parte de la arquitectura, no limpieza doméstica.

Cada campo es un compromiso

Una vez que un campo está ahí afuera recogiendo datos, todo empieza a apoyarse en él. Las pantallas lo muestran, los flujos se ramifican según él, las reglas de validación lo comprueban, los informes agrupan por él, las integraciones lo envían y lo leen, y ahora las herramientas de IA razonan sobre él. Cada uno de ellos hace suposiciones sobre el campo: su tipo, su longitud, si alguna vez está en blanco y qué significan sus valores. Si cambias el campo más adelante, primero tienes que encontrar cada una de esas suposiciones. Renombrar un valor de una lista de selección, acortar un campo de texto o convertir un campo de Texto en una lista de selección suena a un cambio pequeño, y puede romper una integración en el sistema de otra empresa. Por eso un campo es un compromiso.

Click to enlarge

No quiero que salgas de este módulo con miedo a crear campos. Salesforce está hecho para extenderse; úsalo. Quiero que la pregunta cambie de “¿qué tipo de campo elijo?” a “¿qué significan estos datos y con qué comportamiento nos estamos comprometiendo?”. Tipo, obligatorio, único, ID externo, lista de selección, fórmula, descripción, clasificación: juntos son la expresión física del modelo lógico del capítulo 2.

Lo que decide aquí un arquitecto

• Qué significa el valor antes de elegir el tipo de campo, y si es un atributo, un identificador, un vocabulario controlado o en realidad otra entidad.
• Si un valor es un cálculo actual que puede derivarse o un hecho histórico que hay que guardar.
• Qué sistema es dueño de cada identificador, y si su unicidad es una promesa real del negocio.
• Cuándo se conoce realmente un valor obligatorio, y qué pasa con los registros y las integraciones que no lo tienen.
• Qué descripción, nombre y clasificación necesita el campo para que las personas, los procesos y la IA puedan usarlo con seguridad.

Explora

• Ayuda de Salesforce, Data Classification Metadata Fields (opens in a new tab) (en inglés), consultado el 2026-10-02.
• Ayuda de Salesforce, Einstein Trust Layer: Designed for Trust (opens in a new tab) y Data Masking Limitations in Agentforce (opens in a new tab) (en inglés), consultado el 2026-10-02.
• Salesforce Developers, Insert or Update (Upsert) a Record Using an External ID (opens in a new tab) (en inglés), consultado el 2026-10-02.
• Ayuda de Salesforce, Picklist Limitations (opens in a new tab) (en inglés), consultado el 2026-10-02.
• Ayuda de Salesforce, Formula Field Limits and Restrictions (opens in a new tab) (en inglés), consultado el 2026-10-02.
• Salesforce Developers, Date Formats and Date Literals (opens in a new tab) (en inglés), consultado el 2026-10-02.