Tipos de campo y validación
Esta página es la referencia de los campos que podés agregar a una entidad: qué tipo elegir, qué opciones tiene cada uno y qué reglas se verifican cuando alguien guarda un registro. Para administrar campos necesitás configure_entities; se hace desde Configuración → Constructor de app → Entidades → (entidad) → Campos.
Tipos de campo
| Tipo (como aparece en el asistente) | Guarda | Cómo se ve | Opciones propias |
|---|---|---|---|
| Text | Texto corto | Input de una línea | Largo máximo (default 255) |
| Text Area | Texto largo | Área de varias líneas | Largo máximo (default 5.000) |
| Number | Número | Input numérico | Mínimo, máximo, decimales |
| Currency | Monto de dinero | Número con el símbolo de la moneda del registro | Mínimo, máximo, decimales. La moneda no se elige por campo: ver Monedas |
| Dirección de email | Link mailto: | Largo máximo (default 255) | |
| Phone | Teléfono | Link tel: | Largo máximo (default 50) |
| Date | Fecha | Selector de fecha | — |
| Date & Time | Fecha y hora | Selector de fecha y hora | — |
| Checkbox | Sí / No | Casilla | — |
| Picklist | Una opción de una lista | Desplegable (o combo si no restringe valores) | Opciones con etiqueta, valor interno y color; restringir valores |
| Multi-Select Picklist | Varias opciones de una lista | Chips | Igual que Picklist |
| Relationship | Un registro de otra entidad | Nombre del registro, con vista previa al pasar el mouse | Entidad destino, campo a mostrar |
| URL | Dirección web | Link | Largo máximo (default 2.000) |
Opciones comunes a todos
- Label — lo que ve el usuario. Editable siempre.
- Nombre de API — identificador técnico (
close_date). Se usa en automations, fórmulas, import/export y la API. No se puede cambiar después de crear el campo. - Descripción y placeholder — ayuda contextual en el formulario.
- Requerido — el formulario no deja guardar sin valor, y el servidor lo vuelve a verificar (ver abajo).
- Valor por defecto — se precarga al crear.
Picklist: etiqueta vs. valor interno
Cada opción tiene una etiqueta (lo que se muestra, editable sin consecuencias) y un valor interno (lo que se guarda en el registro y contra lo que comparan filtros, reports y automations). Cambiar el valor interno afecta solo a registros nuevos. También podés asignarle un color a cada opción: se ve en listas, kanban y highlights.
Con Restringir valores activado (el default), el usuario solo elige de la lista. Desactivado, el campo se vuelve un combo que además acepta texto libre.
Campos del sistema
Todo registro tiene, además de tus campos: Creado el / por, Modificado el / por (automáticos, no editables) y Dueño (editable, es un usuario del workspace). Si la entidad tiene tipos de registro, también Tipo de registro; si el workspace usa multi-moneda, Moneda. Aparecen en list views, filtros y páginas aunque no estén en la lista de campos.
Autonumérico
Un campo autonumérico recibe un valor con formato al crear el registro — COT-2026-0042, TCK-0007 — de manera atómica (dos personas creando a la vez nunca reciben el mismo número). Hoy se define al crear la entidad, como tipo del campo principal; los paquetes también lo usan en sus entidades (CPQ numera cotizaciones y contratos así).
- Formato: texto libre con tokens.
{YYYY}/{YY}año,{MM}mes,{NNNN}secuencia con ese relleno de ceros ({NN},{NNN},{NNNNN}también valen). - Alcance: la secuencia se reinicia nunca, por año o por mes.
- Valor inicial de la secuencia.
- Si el dato llega con el campo ya completo (una importación que conserva números históricos), se respeta ese valor.
- Cambiar el formato después no renumera lo existente: los registros viejos quedan con el formato viejo y la secuencia sigue desde donde estaba.
El número se asigna antes de que corran las automations y la validación, así que ambas ya lo ven puesto. Los formularios públicos y los formularios de creación no muestran este campo: no hay nada que completar.
Qué se valida al guardar
Cada vez que un registro se crea o se edita —desde la pantalla, una automation, un Stepper, una importación, un formulario público o la API— el servidor verifica el dato contra la definición de los campos. Si algo falla, no se guarda nada y se informan todos los errores juntos.
| Regla | Qué rechaza | Mensaje que ve el usuario |
|---|---|---|
| Tipo de dato | Un texto donde va un número, una fecha inválida, una relación que no apunta a un registro | ”Campo tiene un valor que no corresponde a su tipo” |
| Requerido | Vacío, solo espacios o una lista sin elementos (un “No” en un checkbox sí es un valor) | “Campo es obligatorio” |
| Valores permitidos | En picklists que restringen valores, cualquier opción fuera de la lista | ”Campo tiene un valor que no está entre sus opciones” |
| Largo | Texto más largo que el máximo del campo | ”Campo es demasiado largo” |
| Rango | Número fuera del mínimo/máximo | ”Campo está fuera del rango permitido” |
| Formato | Email, URL o teléfono mal formados | ”Campo tiene un formato inválido” |
| Único | Un valor repetido en un campo marcado como único | ”ya existe otro registro con ese Campo” |
Antes de validar, el servidor convierte lo que llega: un webhook o un formulario mandan todo como texto, así que "42" en un campo numérico se acepta como 42. Lo que se rechaza es lo que no se puede convertir.
Algunas consecuencias prácticas:
- Una edición parcial valida solo lo que toca. Si un registro viejo tiene vacío un campo que hoy es requerido, podés editarle otro campo sin que te lo exija; te lo va a pedir cuando edites ese campo.
- Las automations “antes de guardar” corren antes de la validación: si una automation completa un campo requerido, la validación ya lo ve completo.
- La importación valida fila por fila: las filas que fallan quedan reportadas con su motivo y las demás entran.
- Único hoy lo definen los paquetes (por ejemplo, el número de cotización) o la metadata; el asistente de campos todavía no ofrece marcarlo.
El orden completo —permisos, autonumeración, automations, validación, guardado, sharing, historial— está en Qué pasa al guardar un registro.