Cada vez que se guarda un registro —desde la pantalla de siempre, desde una automation, desde un Stepper, desde un formulario público, desde una importación, desde un email entrante o desde la API— pasan las mismas cosas, en el mismo orden. No hay atajos: un contacto creado por un webhook recorre exactamente los mismos pasos que uno cargado a mano.
Conocer ese orden explica casi todas las preguntas del tipo “¿por qué se guardó igual?”, “¿por qué no se guardó nada?” o “¿por qué el email llegó tarde?”.
El orden de ejecución
Los pasos 1 al 6 son una sola operación: o pasan todos, o no se guarda nada. Los pasos 7 al 9 ocurren después de que el registro ya existe.
Paso por paso
1 · Permisos
Se verifica que la persona pueda crear, editar o eliminar registros de esa entidad, según sus permission sets. Si no puede, la operación se corta ahí: no se ejecuta ninguna automation ni se toca ningún dato.
Dónde se configura: Configuración → Acceso y seguridad → Usuarios / Permission Sets. Ver Usuarios y permisos.
Los procesos internos del sistema (por ejemplo, el procesamiento de un email entrante) corren sin un usuario detrás y por eso no pasan por este chequeo. Todo lo demás sí.
2 · Numeración automática
Los campos autonumerados que estén vacíos reciben su número (COT-0001, TCK-0042). Ocurre antes que todo lo demás para que las automations y la validación ya vean el número puesto.
Dónde se configura: al crear la entidad, eligiendo Autonumérico como tipo del campo principal. Ver Tipos de campo → Autonumérico.
3 · Tipo de registro y moneda
Se resuelve el tipo de registro: si el que llegó no es válido —o no vino ninguno— se usa el tipo por defecto de la entidad. La moneda se estampa al crear y queda fija para ese registro, aunque después cambie la moneda corporativa.
4 · Automations “antes de guardar”
Corren las automations con disparador antes de crear o antes de actualizar. Son las únicas que pueden:
- Completar o corregir datos antes de que se guarden (por ejemplo, armar el nombre a partir de otros campos, o poner un valor por defecto calculado).
- Cancelar la operación con un mensaje propio. En ese caso no se guarda nada y la persona ve ese mensaje.
Ver Triggers y nodos.
5 · Validación
Acá se revisa el dato contra la configuración de los campos de la entidad. Si algo no pasa, no se guarda nada — ni siquiera parcialmente.
| Qué se revisa | Qué rechaza |
|---|---|
| Tipo de dato | Un texto donde va un número, una fecha que no es fecha, una relación que no apunta a un registro |
| Campos obligatorios | Vacío, solo espacios o una lista sin elementos. Un No en un campo Sí/No es un valor válido |
| Valores permitidos | En listas con “restringir valores”, cualquier opción fuera del listado |
| Largo | Textos más largos que el máximo del campo |
| Rango | Números fuera del mínimo/máximo del campo |
| Formato | Emails, URLs y teléfonos mal formados |
| Duplicados | Un valor repetido en un campo marcado como único |
Dónde se configura: Configuración → Constructor de app → Entidades → (tu entidad) → Campos. Cada campo define si es obligatorio, sus valores permitidos, su largo y su rango (el detalle de cada regla está en Tipos de campo y validación).
Los errores se informan todos juntos, no de a uno: si faltan tres campos, la respuesta lista los tres.
6 · Se guarda
Recién acá el registro toca la base de datos.
7 · Reglas de acceso
Se aplican los accesos: el dueño, la jerarquía de roles y las reglas de compartir que correspondan. En una edición se re-evalúan: si un cambio hace que el registro deje de cumplir una regla, el acceso que esa regla otorgaba se revoca.
Dónde se configura: Configuración → Acceso y seguridad → Roles y Sharing Rules. Ver Sharing.
8 · Historial de campos
Los campos con seguimiento activado registran el cambio: qué valor tenían, cuál quedó, quién lo cambió y cuándo. Solo los campos marcados; el resto no deja rastro.
Dónde se configura: Configuración → Constructor de app → Entidades → (tu entidad) → History Tracking. Ver Entidades → History Tracking.
9 · Automations “después de guardar”
Corren las automations después de crear o después de actualizar: mandar un email, crear una tarea, avisarle a alguien, actualizar otro registro.
Corren en segundo plano, así que la persona no espera a que terminen. Y como el registro ya está guardado, si una de estas automations falla, el registro igual queda guardado.
Si una automation guarda un registro, ese guardado vuelve a recorrer esta misma lista —incluidos sus propios triggers—. Para que dos automations que se disparan entre sí no queden dando vueltas para siempre, el encadenamiento tiene un límite de profundidad: al alcanzarlo, la cadena se corta y queda avisado en el log del servidor.
Qué significa esto en la práctica
“Marqué un campo como obligatorio y una automation vieja empezó a fallar.” Es esperable: esa automation creaba registros sin ese campo. Antes pasaba porque el dato no se revisaba; ahora sí. Hay que completar el campo en la automation.
“Un paso de mi Stepper falla al crear el registro.” El mensaje dice qué campo falta. Si el paso toma el valor de una pantalla anterior, revisá que la variable exista con ese nombre: una referencia a una variable que no existe se resuelve vacía, y el campo llega sin valor.
“Mi automation completa un campo obligatorio. ¿Va a fallar?” No. Las automations “antes de guardar” corren en el paso 4 y la validación en el paso 5: lo que la automation complete ya está puesto cuando se valida.
“Falló la validación. ¿Se guardó algo a medias?” No. Nada se guarda hasta el paso 6.
“El registro se creó pero no llegó el email de aviso.” El email lo manda una automation “después de guardar”, que corre en segundo plano. El registro se guarda igual aunque ese envío falle. Revisá el historial de ejecuciones de la automation — ver Debugging y límites.
“Importé 500 filas y algunas no entraron.” La importación valida fila por fila con las mismas reglas. Las que no pasan quedan reportadas con su motivo; las demás se importan. Ver Importar / exportar.
“Un registro viejo tiene un campo obligatorio vacío.” Puede pasar: la regla se aplica al guardar, no retroactivamente. Ese registro queda como está hasta que alguien lo edite; ahí sí se le va a pedir completarlo.
Al eliminar
Eliminar es más corto, pero también tiene su orden:
El registro y sus notas se eliminan juntos: no quedan notas huérfanas apuntando a algo que ya no existe.
Eliminar un registro no se puede deshacer desde la aplicación.