Cuando configuras una automatización para Asignaciones (por ejemplo “Al realizar una asignación” o “Al vencimiento de una asignación”), el flujo recibe un conjunto de datos con una estructura fija. Conocer esa estructura te ayuda a configurar los pasos del flujo en inData Workflow, porque los mismos bloques y campos que se describen aquí son los que verás al conectar los datos entrantes.

Visión general

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

{
  "my_info": {
    "meta": { ... },
    "data": {
      "subject": { ... },
      "assignment": { ... },
      "solution": { ... }
    }
  }
}

• meta: Metadatos del evento: identificador único del evento, fecha y hora, cuenta, módulo, acción, identificador de la asignación cuando el evento está asociado a una asignación concreta (entity_id), e identificador del flujo.
• data.subject: Tipo de registro (assignment) e identificadores: record_id es el ID de la asignación cuando el evento está asociado a una asignación concreta.
• data.assignment: Datos de la asignación: origen legible, zona (identificador y nombre), jornada (identificador y nombre/horario), formulario o actividad (identificador y nombre), usuario asignado (identificador, usuario y nombre completo), cliente, sede, fechas, y si está cumplida los identificadores del registro cumplido (form_id, local_id). Solo se rellena cuando el evento está asociado a una asignación concreta (por ejemplo porque en la regla indicaste una asignación o un puesto). Si no, data.assignment será null y la regla se evalúa como general.
• data.solution: Si la asignación está cumplida, el registro del formulario cumplido en formato simplificado: fechas en formato legible, sucursal por nombre, respuestas y datos útiles para el flujo. Solo está presente cuando la asignación está realizada y el sistema puede recuperar ese registro; en caso contrario no se envía o es null.

Si no se envía o no se puede resolver el ID de la asignación, data.assignment será null y la regla se evalúa como general (sin datos de cliente, sede, zona, etc.).

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

En el diseñador del flujo verás esta misma jerarquía: el objeto principal my_info, dentro de él meta y data, y dentro de data los bloques subject, assignment y solution (cuando existan).

Cuándo llegan los datos de la asignación

Si la automatización se dispara sobre una asignación concreta (por ejemplo porque en la regla indicaste un puesto o una asignación específica, o porque el evento viene asociado a una asignación), data.assignment vendrá rellenado con la información de esa asignación.

Si el evento no está asociado a una asignación concreta (regla “general”), data.assignment será null y el flujo solo tendrá meta y data.subject con información básica del evento.

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 (asignaciones).
• action: acción concreta (por ejemplo realizar_asignacion o vencimiento_asignacion).
• entity_id: identificador de la asignación cuando el evento está asociado a una asignación concreta; 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 asignaciones será “assignment”.
• form_id: identificador del formulario si aplica (opcional).
• local_id: identificador del registro cumplido si la asignación está realizada (opcional).
• record_id: identificador de la asignación cuando el evento está asociado a una asignación concreta.

Contenido de data.assignment

Cuando data.assignment no es null, contiene la información de la asignación. Los campos que no existan o no apliquen pueden llegar vacíos o nulos.

Identificación y origen

• id_account_customer_homework: identificador de la asignación (el mismo que ves en inData).
• id_survey_base: identificador del formulario o actividad que debe cumplirse.
• source: origen técnico de la asignación (programacion_puesto, programacion, solution, manual, mobile, etc.).
• origen: origen en texto legible (“Programación Puesto”, “Programación”, “Solución”, “Móvil”).
• is_programada: si la asignación viene de programación.
• is_creada_en_movil: si la asignación fue creada desde la app móvil.

Fechas y estado

• start_at: fecha y hora de inicio (formato estándar día y hora).
• end_at: fecha y hora de fin.
• is_done: 1 si la asignación está realizada, 0 si no.

Zona y ubicación geográfica

• id_account_geo_zone / id_zona: identificador de la zona (cuando aplica).
• geo_zone_name: nombre de la zona (por ejemplo “Zona Norte”, “Zona Centro”).
• geo_zone_code: código de la zona (si existe).
• geo_city_name: nombre de la ciudad (por ejemplo “Ciudad Ejemplo”, “Localidad Ejemplo”).
• geo_city_code: código de la ciudad (si existe).

Jornada (turno)

• id_turno_jornada: identificador de la jornada (cuando la asignación está vinculada a una).
• turno_jornada_name: nombre y horario de la jornada (por ejemplo “Diurna (08:00 - 17:00)”).

Algunas asignaciones no tienen jornada asociada; en ese caso estos campos pueden ser null.

Actividad o formulario

• survey_base_name: nombre del formulario o actividad (por ejemplo “Revista de supervisión”), el mismo que ves en inData.

Usuario asignado

• id_assigned_user: identificador del usuario asignado (cuando la asignación tiene uno).
• assigned_user_username: usuario (login) del usuario asignado.
• assigned_user_full_name: nombre completo (nombre y apellido, o el usuario si no hay nombre).

Si la asignación no tiene usuario asignado (en inData aparece “Sin especificar”), estos campos serán null.

Cliente y sede

• id_account_customer_point: identificador de la sede (punto).
• id_account_customer: identificador del cliente.
• customer_point_name: nombre de la sede.
• customer_point_address: dirección de la sede.
• customer_name: nombre del cliente.
• customer_code: código del cliente.
• customer_business_name: razón social.
• customer_alias: alias del cliente.
• customer_identification: identificación del cliente (NIT o documento).

Cuando la asignación no tiene cliente o sede asociados, los campos correspondientes pueden ser null.

Registro cumplido (dentro de assignment)

• form_id: identificador del formulario del registro cumplido (si la asignación está realizada).
• local_id: identificador del registro (local) de ese envío (si la asignación está realizada).

Contenido de data.solution

Cuando la asignación está realizada y el sistema puede recuperar el registro del formulario cumplido, se envía además el bloque data.solution con los datos de ese registro: respuestas, fechas de envío en formato legible (zona horaria de tu cuenta), nombre de la sucursal, usuario que envió, etc. Así puedes usar en el flujo la información concreta del cumplimiento sin consultar otras pantallas.

Si la asignación no está realizada o no se puede recuperar el registro, data.solution no estará presente o será null.

Resumen rápido

• Estructura: un objeto con meta (información del evento) y data (con subject, assignment y solution cuando aplican). Esta es la misma estructura que verás al configurar el flujo.
• Evento con asignación concreta: data.assignment viene rellenado; si además la asignación está realizada, puede venir data.solution.
• Evento sin asignación concreta: data.assignment y data.solution serán null.
• Asignación sin usuario asignado: en data.assignment los campos de usuario asignado serán null.
• Asignación sin jornada asociada: en data.assignment los campos de jornada pueden ser null.