Cuando configuras una automatización para Formularios con la acción "Al crear un registro", el flujo se ejecuta cada vez que se crea un nuevo registro (solución) de un formulario —desde la app móvil o desde la web—. En este artículo se explica qué información llega al flujo y qué nombres de campo usar en el diseñador para conectar los datos entrantes.

Para probar el evento sin afectar producción puedes usar el simulador de eventos: en la configuración de simulación elige Módulo: Formularios, Acción: Al crear un registro y, si quieres, Formulario (opcional) para acotar a un formulario concreto. El flujo que indiques en "Workflow" recibirá el evento de prueba con la misma estructura que se describe aquí.

Visión general

El flujo recibe un único objeto llamado my_info, con esta estructura:

{
  "my_info": {
    "meta": { ... },
    "data": {
      "subject": { ... },
      "form_id": ...,
      "local_id": ...,
      "result": { ... },
      ...
    }
  }
}

• meta: Metadatos del evento: identificador único del evento, fecha y hora, cuenta, módulo (formularios), acción (crear_registro), entity_id (identificador del formulario cuando la regla está asociada a un formulario concreto) e identificador del flujo.
• data.subject: Tipo de registro ("solution") e identificadores del registro: form_id, local_id, record_id.
• data (además de subject): Incluye los datos del registro creado: form_id, local_id, account_id, type_wf, record_id, record_code, fechas de envío en formato legible (start_at, send_at, sent_at, ts), result (objeto con las respuestas del formulario por nombre de campo), user, user_email, sucursal (cuando aplica), y otros campos útiles. Las fechas se envían en la zona horaria de tu cuenta.

Si el sistema no puede recuperar el registro (por ejemplo porque form_id o local_id no se enviaron o no existen), data tendrá solo subject y el resto de campos no estarán presentes o vendrán vacíos.

Estructura general (qué verás en el diseñador)

En el diseñador del flujo verás la jerarquía my_info → meta y data; dentro de data, el bloque subject y el resto de campos del registro (form_id, local_id, result, etc.) al mismo nivel. Los nombres que se listan abajo son los que debes usar al conectar los datos entrantes en un paso del flujo.

Cuándo llegan los datos del registro

El evento "Al crear un registro" se dispara cuando la aplicación (móvil o web) indica que se ha creado un nuevo registro de un formulario. Para que el flujo reciba los datos completos del registro (respuestas, fechas, usuario, sucursal, etc.), el evento debe enviar subject.form_id y subject.local_id. Con esos datos el sistema consulta el registro y rellena data con la información en formato legible. Si no se envían o no se encuentra el registro, data contendrá solo subject con los identificadores básicos.

Contenido de meta

En todos los casos meta incluye:

• event_id: identificador único de esta ejecución del evento (para trazabilidad).
• occurred_at: fecha y hora del evento (si la aplicación la envía).
• id_account: identificador de tu cuenta (tenant).
• module: módulo que disparó la automatización (formularios).
• action: acción concreta; para este evento será crear_registro.
• entity_id: identificador del formulario cuando la automatización está asociada a un formulario concreto; si no, puede ser null.
• flow_id: identificador del flujo que se está ejecutando.

Contenido de data.subject

data.subject incluye:

• type: tipo de registro; para formularios será "solution".
• form_id: identificador del formulario (id_survey_base).
• local_id: identificador local del registro recién creado (el que identifica ese envío en el formulario).
• record_id: identificador interno de la solución (id_survey_solution o equivalente), si se envió en el evento.

Contenido de data (datos del registro creado)

Cuando el sistema puede recuperar el registro, data incluye además de subject los siguientes campos. Los que no existan o no apliquen pueden llegar vacíos o nulos.

Identificación y contexto

• form_id: identificador del formulario.
• local_id: identificador local del registro.
• account_id: identificador de la cuenta.
• type_wf: tipo de workflow (por ejemplo "Solution").
• record_id: identificador interno de la solución.
• record_code: código del registro (si existe).
• version: versión del documento (si existe).

Fechas (en zona horaria de tu cuenta)

• start_at: fecha y hora de inicio del envío (formato legible).
• send_at: fecha y hora en que se envió (formato legible).
• sent_at: fecha y hora de envío registrada (formato legible).
• ts: timestamp de envío en formato legible.

Usuario y origen

• user: usuario que creó/envió el registro (si se registró).
• user_email: correo del usuario (si existe).
• source: origen del envío (móvil, web, etc.), si se registra.

Respuestas del formulario

• result: objeto plano con las respuestas del formulario. Cada clave es el nombre del campo (saneado, sin caracteres especiales); el valor es la respuesta. Por ejemplo: result.nombre_contacto, result.sucursal, result.observaciones. Si el formulario tiene subformularios (tablas repetibles), esas partes vienen como array de objetos para que puedas recorrerlas en el flujo. El campo sucursal (cuando existe) se envía como nombre de la sede, no como ID, para que puedas usarlo directamente en mensajes o condiciones.

Ubicación y datos adicionales

• geolocation: datos de geolocalización en el momento del envío (si se capturaron).
• coords: coordenadas (si existen).
• coords_delta: variación de coordenadas (si se registra).
• homework: identificador de asignación si el registro está vinculado a una (opcional).
• is_homework_local: si es envío local de una asignación (opcional).
• solution_data: datos crudos adicionales del documento (si el sistema los expone).

Las rutas de archivos que correspondan a almacenamiento interno del dispositivo se sustituyen por un texto genérico por seguridad; el resto de valores de las respuestas llega tal como se guardó.

Resumen rápido

• Estructura: my_info con meta (información del evento) y data (subject + datos del registro cuando se puede recuperar). Usa los nombres de campo indicados arriba en el diseñador del flujo.
• Evento "Al crear un registro": se dispara al crearse un nuevo registro del formulario. Para recibir datos completos, el evento debe incluir form_id y local_id en subject.
• data.result: contiene las respuestas del formulario por nombre de campo; result.sucursal viene como nombre de la sede cuando aplica.
• Fechas: start_at, send_at, sent_at, ts en formato legible y en la zona horaria de tu cuenta.
• Para probar sin afectar producción: usar el simulador con Módulo Formularios, Acción "Al crear un registro" y opcionalmente un Formulario concreto.