BModeler | 4. Procesos (Actividades)

[Anahi_Blanco (Anahí Blanco)]

4. Procesos

4.1 Actividades

4.1.1 Inicio

El elemento de Inicio en BModeler es el punto de partida obligatorio de cualquier proceso y define la modalidad en la que se generarán los casos. Se encuentra en la barra de actividades, desde donde se puede arrastrar al lienzo.

Cuando se arrastra la actividad al lienzo, automáticamente se abre la ventana de configuración en la parte izquierda de la pantalla.

Se debe definir el Nombre y el Tipo para poder guardar la configuración.

Existen tres tipos principales de inicio que un usuario puede configurar:

Inicio Directo (Manual o por API)

Este tipo de inicio permite que el proceso comience de forma inmediata, ya sea por la acción de un usuario o por un sistema externo.

• Manual: El usuario inicia el caso directamente desde la prestación de “Casos” haciendo clic en el botón de “Nuevo Caso”.

• Datos de API: Se obtiene la API que permite disparar el proceso desde sistemas externos o desde el propio ERP (transacciones de Go).

• Configuración de Parámetros: Si se colocan parámetros, al iniciar el caso estos parámetros tienen que ser completados para dar inicio definitivo. Si se opta por el inicio vía API, el administrador puede definir parámetros específicos (como el nombre de un proveedor). A medida que se agregan estos parámetros, el sistema construye automáticamente el cuerpo del JSON que la API esperará recibir para iniciar el caso exitosamente.

Inicio por Formulario

Se utiliza cuando se requiere que el usuario cargue información específica antes de iniciar el caso.

• Maquetador Visual: Requiere la configuración de un formulario mediante una herramienta de “arrastrar y soltar” (drag and drop) donde se definen los campos necesarios.

• Limitación actual: A diferencia del inicio directo, los procesos que inician por formulario no pueden ser llamados por API actualmente; siempre requieren que el usuario haga clic en “Nuevo Caso” e complete los datos manualmente.

Inicio Programado (Automático)

Este inicio no requiere intervención humana ni llamadas externas, ya que el sistema genera los casos de forma autónoma basándose en una agenda predefinida.

• Se debe seleccionar un tipo de programación:

• Por Intervalo: Se define una hora de inicio, una de fin y la frecuencia de ejecución (ej. cada 30 minutos o cada 2 horas) dentro de ciertos días, pudiendo activar el toggle para indicar “Todos los dias” o haciendo clic sobre días específicos.

• Hora Programada: El caso se dispara en una hora exacta y en los días de la semana seleccionados.

• Fecha Relativa: Permite configuraciones basadas en el calendario, como el primer o último día del mes, o fechas fijas semestrales.

• Asignación de Propietario: Como no hay un usuario físico iniciando el trámite, es obligatorio asignar un propietario al caso (usuario de Go) para que alguien sea responsable de supervisar o visualizar el avance de esos casos automáticos. Aplica a todos los tipos.

Importante: Para que se comiencen a generar los casos de un proceso con inicio programado debe estar activo el inicio. En caso de que se requiere desactivar por algún motivo para pausar la creación de casos en esta modalidad, se puede inactivar sin perder la configuración.

4.1.2 Actividad de usuario

La Actividad de usuario representa una tarea que debe ser ejecutada por una persona, ya sea un usuario interno del sistema o un usuario invitado (no tiene usuario en Finnegans). Desde esta actividad se ofrece la posibilidad de crear un formulario dinámico de forma customizable.

Esta actividad se divide estructuralmente en tres secciones clave: información de la actividad, el formulario y las notificaciones.

Información de la actividad

En esta sección se define el nombre de la actividad, quién debe ejecutar la tarea, tratamiento de reasignación y tratamientos de rechazos o devolución.

Una de las diferencias sustanciales de BModeler respecto a sistemas anteriores es su capacidad para interactuar con personas que no tienen usuario en el sistema.

Asignar Responsables:

• Usuarios Internos: Se pueden asignar a un usuario único, que se puede seleccionar si está guardado en un atributo, o escribirlo como constante, ó a equipos predefinidos en la prestación BModeler-Equipos. Estos usuarios acceden a la tarea desde la prestación “BModeler Casos”.

• Responsable Invitado (Externo): Permite que personas externas (como proveedores) completen formularios sin tener usuario en el ecosistema Finnegans. Reciben un correo con un link seguro que los lleva directamente al formulario, con un tratamiento de seguridad especial. Se puede asignar a un único usuario, seleccionando desde atributo o escribiendo como constante, o una lista de usuarios, que también puede estar en un atributo o escribir las direcciones de correo electrónico separadas por “punto y coma”.

• Permiso de Reasignación: La opción “Permite asignar usuario” habilita a la persona asignada a derivar la tarea a otro usuario durante la ejecución del caso. Esta funcionalidad es exclusiva para usuarios internos y no aplica para externos.

• Tratamiento de Rechazo y Devolución

El administrador puede configurar botones específicos para gestionar flujos alternativos o correcciones.

• Rechazo: Conceptualmente, el rechazo siempre avanza hacia adelante en el flujo; puede finalizar el proceso o llevarlo a una etapa de cierre definitivo.

• Devolución: Esta acción permite enviar el caso hacia atrás, específicamente a la actividad de usuario inmediata anterior.

  • Atributos: Al devolver un caso, los datos cargados en los atributos se preservan, permitiendo que el usuario anterior realice las correcciones necesarias.

  • URL de anulación: Si en el camino de regreso hubo una actividad automática (como una API que impactó datos), se puede configurar una URL de anulación para ejecutar una regla que revierta estos cambios automáticamente.

Formulario

Toda actividad de usuario está ligada obligatoriamente a un formulario diseñado mediante un maquetador visual de “arrastrar y soltar”.

• Propiedades de los Campos: Los campos (widgets) pueden marcarse como requeridos (obligatorios para avanzar) o de solo lectura.

• Diseño y Visualización:

  • Paginado: El formulario puede mostrarse en una sola página con desplazamiento o dividirse en pasos, donde cada contenedor actúa como una página nueva.

  • Responsividad: El maquetador permite previsualizar cómo se verá el diseño en PC, tablet y celular. Se recomienda el uso de una sola columna para asegurar una visualización correcta en dispositivos móviles.

• Persistencia de Datos: Es crítico vincular cada campo del formulario a un atributo del proceso; si no se guarda en un atributo, la información se perderá y no podrá ser manipulada en etapas posteriores del flujo.

Notificaciones

Permiten dar aviso al responsable de que tiene una tarea pendiente.

• Canales: Se pueden configurar por Mail y/o WhatsApp (si el servicio está vinculado).

• Personalización: El sistema permite utilizar las plantillas predeterminadas o personalizar el asunto y el cuerpo del mensaje. En el caso del mail, es posible incluso redactar contenidos específicos para cada actividad.

4.1.3 Actividad automática

La actividad automática en BModeler es una actividad del diagramador que agrupa tareas ejecutadas directamente por el sistema, sin necesidad de que intervenga un usuario. Al arrastrarla al lienzo, inicialmente aparece con un icono de rueda dentada, pero una vez configurada, el icono cambia para reflejar la función específica asignada.

Estas actividades cuentan con una funcionalidad clave para los diseñadores de procesos y es la de “Ejecutar prueba”, este botón se encuentra en las actividades de envío de mail, API y Agente IA. Esto permite validar si una configuración (como un envío de mail o una búsqueda de IA) funciona correctamente de forma aislada, sin necesidad de iniciar un caso completo ni recorrer todo el diagrama desde el principio.

A continuación, se detallan las principales herramientas y funcionalidades disponibles dentro de este tipo de actividad:

Notificaciones

Mail

• Configuración Dinámica: Permite enviar correos electrónicos de forma automática a destinatarios fijos o dinámicos (utilizando atributos como el “Propietario del caso”).

• Personalización con HTML: El cuerpo del mensaje admite la estructura de etiquetas HTML para otorgar un diseño profesional, incluyendo logotipos y formatos específicos.

• Uso de atributos: Se pueden insertar datos del proceso en el asunto o cuerpo del mail utilizando la nomenclatura ${nombre_del_atributo}, lo que permite que el sistema reemplace el código por el valor real del caso.

Ejemplo de configuración

1. Se completaron todos los datos obligatorios.

2. Se generó un HTML con IA y lo pegamos en el body.

3. Se hace clic en el botón “Ejecutar prueba”

4. Aparece un mensaje que se ejecutó con éxito la prueba unitaria.

5. Así se visualiza el mail en destino.

Gestión de Datos y Archivos

Conversor de formatos

Esta actividad toma información almacenada en un atributo de tipo JSON y la convierte en archivos descargables.

• Datos de entrada: se debe seleccionar el atributo en el cual se tiene guardado el archivo a convertir, se espera que el formato sea JSON. En el ejemplo se crea un nuevo atributo, pero este atributo, puede estar creado y se debe seleccionar directamente.

• Formatos de Salida: Los archivos resultantes pueden generarse en formato CSV, XLS o XLSX.

• Atributo de destino: El archivo generado debe guardarse obligatoriamente en un atributo de tipo Archivo. Como en toda la herramienta, el atributo lo puedo seleccionar, si fue creado previamente o crearlo en el momento de la configuración.

• Nombre del archivo: El usuario puede proporcionar un nombre al archivo generado. En el caso de las extensiones .xls y .xlsx se podrá asignar también nombre a la hoja.

• Mapeo de Columnas: El usuario puede definir qué campos del JSON original se convertirán en columnas del archivo y asignarles nombres personalizados (ej. cambiar “sku” por “Código de producto”).

Importante: la lectura de los datos es nivel “objeto”, en la imagen lo que se observa es que el JSON tiene una estructura “lista de objetos”.

Una vez que se seleccionan los datos se presentan de forma que se pueda mapear el nombre, según lo requerido.

Integraciones

API

Permite conectar el proceso con el ERP de Finnegans o sistemas externos:

• Método HTTP: Selección del tipo de petición a realizar (GET, POST, PUT, PATCH, DELETE).

• URL de la API: Dirección del endpoint al cual se realizará la consulta.

• Configuraciones Extra: Paneles desplegables para definir:

  • Parámetros: Query params para la URL.

  • Cabecera (Headers): Definición de tokens de autenticación, content-type, etc.

  • Body: Cuerpo de la petición (disponible para métodos POST, PUT y PATCH).

• Guardar respuesta en: Selector para elegir el Atributo del Proceso donde se almacenará el resultado (JSON o texto) devuelto por la API para ser usado en pasos posteriores. En el caso que no sea la recepción de datos, se guardará la respuesta respecto a la conexión.

Guest Code

Facilita la integración con Guest Code, para crear o buscar el endpoint de scripts en Python asistidos por inteligencia artificial. El diagramador permite configurar el punto de acceso (endpoint) del script directamente en una llamada API.

En este punto, si el script ya existe en nuestro espacio de trabajo, podemos editar o copiar el nombre y endpoint para utilizar posteriormente.

Para copiar podemos seleccionar “Copiar URL”.

Alternativamente, podemos hacer doble click sobre el endpoint que nos interesa, y se abrirá una ventana con la opción de editar el script. Desde ahí, también se podrá copiar el endpoint a configurar.

En caso de querer generar un nuevo script, se debe hacer clic en el botón “Nuevo” y se comienza con la creación.

Inteligencia Artificial

Agente IA

Permite enviar instrucciones a un modelo de IA para redactar textos, analizar datos o realizar búsquedas en internet.

• Interacción con Atributos: Al igual que en los correos, se pueden incluir atributos del proceso dentro del pedido (prompt) a la IA utilizando la sintaxis ${nombre_atributo}. Al escribir los caracteres ${ (pesos + llave de apertura) se despliega la lista de atributos del proceso.

• Almacenamiento de Respuestas: El resultado generado por la IA se guarda en un atributo de texto seleccionado por el usuario.

4.1.4 Controles de flujo

Estas actividades son fundamentales para dirigir, pausar, desviar, retornar o interconectar el recorrido de un caso a lo largo de un proceso de negocio. Su objetivo principal es modelar la lógica de negocio tanto para el “camino feliz” (el flujo estándar) como para gestionar excepciones y caminos alternativos.

4.1.4.1 Compuerta exclusiva

La compuerta de decisión exclusiva es una actividad del diagramador de BModeler que se utiliza para dirigir el flujo de un proceso hacia un camino o hacia otro, basándose en el cumplimiento de una condición específica.

A continuación, se presenta un detalle explicativo de su funcionamiento, requisitos y configuración para los usuarios:

1. Requisito Obligatorio de Conexión

Para poder configurar la lógica de una compuerta exclusiva, es indispensable que primero esté conectada físicamente en el lienzo a dos actividades de salida.

• Si intentas configurar la decisión antes de realizar estas conexiones, el sistema te mostrará un mensaje indicando que la compuerta debe estar conectada a dos actividades para poder avanzar.

2. Configuración de la Decisión

Una vez realizadas las conexiones, al seleccionar la compuerta podrás acceder a su configuración:

• Nombre de la decisión: Se debe definir una etiqueta clara para la condición (por ejemplo, “Aprobado”).

• Dato a evaluar: Es el valor que el sistema va a revisar. Puede ser un valor fijo escrito de forma constante o, lo más recomendado, un atributo o parámetro dinámico del proceso (como la fecha de hoy o el propietario del caso).

• Operadores de comparación: El sistema permite evaluar el dato mediante las siguientes funciones lógicas:

  • Igual

  • Distinto

  • Mayor

  • Menor

  • Mayor o igual

  • Menor o igual

3. Construcción de Condiciones Complejas

BModeler permite crear reglas más avanzadas combinando varias condiciones:

• Conectores lógicos: Puedes utilizar operadores lógicos Y (AND) o O (OR) para evaluar múltiples variables en simultáneo. Por ejemplo: Si la fecha es igual a la de hoy Y el propietario del caso es un usuario específico.

• Uso de paréntesis: Sirven para agrupar las condiciones y estructurar el orden de evaluación lógica.

• Interfaz de Diseño (Drag and Drop): La construcción de la regla se realiza mediante un lienzo visual donde se arrastran y sueltan los conectores, paréntesis y condiciones.

5. Definición de Caminos (Verdadero / Falso)

Una vez que la condición está armada, se configuran las salidas del flujo de manera muy sencilla:

1. El usuario debe indicar qué actividad conectada debe ejecutarse si se cumple la condición (por ejemplo, enviar un mail automático).

2. De forma automática, el sistema asignará la ruta inversa (si no se cumple la condición) a la otra actividad que conectaste previamente, completando así la bifurcación lógica de la compuerta.

4.1.4.2 Compuerta paralela

La compuerta de decisión exclusiva es una actividad del diagramador de BModeler que se utiliza para ejecutar múltiples tareas al mismo tiempo y luego unificar el flujo para que el proceso continúe. A diferencia de la compuerta exclusiva, su lógica no se basa en tomar una decisión o elegir un único camino, sino en habilitar el trabajo en paralelo.

A continuación, se detalla el funcionamiento de esta actividad:

El Ciclo de Divergencia y Convergencia

Este componente trabaja bajo un principio de apertura y cierre del flujo de trabajo:

• Compuerta de Apertura (Divergencia): Es el punto en el diagrama donde un único camino se bifurca en múltiples actividades que se disparan simultáneamente. El maquetador muestra un aviso para recordar al usuario que, para asegurar el correcto funcionamiento del proceso, es obligatorio colocar una segunda compuerta que vuelva a reunir los caminos segmentados.

• Compuerta de Cierre (Convergencia): Es el punto donde todas las actividades que venían ejecutándose en paralelo se vuelven a encontrar para unificar el proceso y permitir que avance hacia las siguientes etapas.

Regla de Sincronización Obligatoria

La compuerta de cierre actúa como un retenedor del proceso:

• Espera al último camino: El flujo del proceso no seguirá adelante bajo ninguna circunstancia hasta que todas las actividades que se lanzaron en paralelo hayan finalizado.

• Ejemplo práctico: Si la compuerta de apertura lanza tres tareas (como un envío de mail automático, una consulta a la inteligencia artificial y un formulario manual para un usuario externo): las actividades del mail y de la IA pueden terminar casi de inmediato. Sin embargo, si el usuario externo no completa el formulario, el caso completo permanecerá pausado en la compuerta de cierre y no avanzará en el flujo principal.

Importante:

• No sirve para elegir caminos opcionales: si el monto es mayor a $1000 ir por flujo A, y si es menor ir por flujo B, no debes usar una compuerta paralela.

• La solución: Para evaluar condiciones y seleccionar un único camino entre tres o más opciones, el usuario debe diseñar y anidar compuertas de decisión exclusivas en el lienzo.

4.1.4.3 Temporizador de fecha

El temporizador de fecha es una actividad del diagramador de BModeler diseñada para establecer plazos de entrega y controlar qué sucede cuando una tarea de usuario no se completa a tiempo.

A continuación, se detalla su comportamiento, reglas de diseño y configuración:

1. Regla Obligatoria de Ubicación (Anclaje)

• A diferencia de otras actividades del diagramador, el temporizador de fecha no puede colocarse directamente sobre el lienzo en blanco.

• Debe arrastrarse y soltarse obligatoriamente encima de una actividad de usuario. Al hacerlo, queda visualmente anclado a esa tarea específica.

2. Configuración del Flujo (Caminos de Salida)

Al igual que las compuertas exclusivas, para poder configurar este elemento, es necesario conectarlo físicamente a las actividades de salida primero:

• Camino Feliz (A tiempo): Es la flecha que sale normalmente de la actividad de usuario hacia la siguiente etapa si el formulario es completado dentro del plazo.

• Camino de Vencimiento (Expirado): Es la flecha que sale directamente desde el icono del temporizador hacia otra actividad (como un envío de mail de alerta o un fin alternativo del proceso) para definir qué camino toma el caso si el tiempo configurado se agota sin respuesta.

3. Modos de Configuración de Tiempo

Al abrir las propiedades del temporizador (una vez conectado), el sistema ofrece dos modalidades para definir el vencimiento: Desde el proceso y En ejecución.

• En ejecución: En este modo, no se preconfigura ningún tiempo en el diagramador. El vencimiento se define al momento de ejecutar el caso.

  • Ejemplo de uso: Está pensado para situaciones donde la tarea se asigna a un equipo completo. Quien tome el caso dentro de ese equipo puede reasignar la tarea a una persona específica y definir manualmente un límite de tiempo personalizado en ese instante.

• Desde el proceso: El límite de tiempo se define rígidamente durante el diseño del diagrama.

  • Se puede establecer una duración constante indicando un valor numérico y seleccionando la unidad de tiempo (día, hora o minuto).

  • También existe la opción de definirlo de forma dinámica seleccionando un atributo del proceso que contenga dicho valor.

4.1.4.4 Compensador de tiempo

El compensador de tiempo es una actividad del diagramador de BModeler diseñada específicamente para detener o pausar el flujo de un proceso durante un período determinado y, una vez transcurrido ese lapso, reanudarlo de forma automática hacia la siguiente etapa.

A continuación, se detallan sus características de configuración, diferencias lógicas y recomendaciones de uso:

¿Para qué sirve y cómo se configura?

• Pausa del proceso: Se utiliza cuando la lógica del negocio requiere una espera obligatoria entre dos acciones. Por ejemplo, se puede colocar en el medio del diagrama para que, tras enviar una notificación, el sistema espere 1 día (o un tiempo determinado) antes de enviar un formulario para completar.

• Configuración del parámetro: Al abrir sus propiedades, el diseñador debe definir el valor correspondiente en el campo de tiempo de espera (“tiempo, espera”).

Diferencia clave con el Temporizador de fecha

Para evitar errores comunes de diseño en el lienzo, es vital comprender que operan bajo lógicas completamente distintas:

• El compensador de tiempo se coloca de manera independiente en el flujo y su única función es congelar transitoriamente el avance general del caso por una cantidad de tiempo (como horas o días) antes de seguir adelante.

• El temporizador de fecha se ancla de forma obligatoria sobre una actividad de usuario y sirve para establecer una fecha límite de entrega, derivando el flujo por un camino alternativo únicamente si el usuario no completa la tarea a tiempo.

Importante: Es indispensable conectar físicamente la salida del compensador hacia la actividad que debe continuar después de la pausa.

4.1.4.5 Conector de proceso

El conector de procesos es una actividad del diagramador de BModeler que sirve como un puente para enlazar y ejecutar un proceso secundario (subproceso) desde el flujo de un proceso principal (proceso padre).

Funcionamiento: Modo Asincrónico

En la versión vigente de la plataforma, este elemento opera bajo una lógica asincrónica:

• Lista de selección: El diseñador simplemente arrastra el componente al lienzo, abre sus propiedades y selecciona de una lista qué proceso existente desea invocar.

• Lanzar y continuar: Cuando el caso activo llega al punto del conector en el diagrama, el sistema dispara el proceso secundario y, de manera inmediata, continúa con el flujo del proceso principal.

• Sin esperas: El proceso padre no espera ninguna respuesta ni confirmación de finalización del proceso hijo para seguir adelante con sus tareas.

Importante: Actualmente, el conector asincrónico solo funcionará de manera exitosa si el proceso al que se llama no requiere ningún parámetro de entrada para iniciarse. En caso de requerirlos, el flujo fallará.

4.1.5 Fin

La actividad fin concluye el flujo de un caso dentro de BModeler. Su configuración en el lienzo es sumamente directa, ya que únicamente requiere que se le asigne un nombre y se conecte con la actividad anterior.

El sistema permite utilizar dos tipos de eventos de fin según las necesidades de diseño:

Fin Común

Es el cierre estándar que se utiliza cuando el proceso se ejecuta con normalidad y finaliza bajo las condiciones deseadas o esperadas (el “camino feliz”).

Fin Alternativo

Este tipo de fin sirve para diferenciar visualmente los distintos desenlaces que pueden tener los casos.

• Lógica de desvío: Se utiliza para separar el camino exitoso de los caminos de excepción o desvíos. Por ejemplo, si una actividad se vence por tiempo y el caso se cierra de manera anticipada, se puede conectar a un fin alternativo.

• Identificación en la grilla de casos: Su gran ventaja es que permite distinguir de forma clara en la grilla de casos cómo terminó cada instancia. De este modo, el usuario puede saber rápidamente si el caso concluyó de la forma planeada o si finalizó debido a un vencimiento u otra causa externa.

• Criterio del usuario: No implica necesariamente un resultado negativo; queda a total consideración de quien diseña el proceso decidir si lo utiliza para reconocer un vencimiento, un rechazo o simplemente un flujo de cierre administrativo diferente

4.1.6 Maquetador de formulario

El maquetador de formularios de BModeler es la herramienta visual integrada dentro de las actividades de inicio (por formulario) y las actividades de usuario. Está diseñado bajo una interfaz de “arrastrar y soltar” (drag and drop), lo que permite a los diseñadores estructurar campos de manera sencilla para que los usuarios finales —tanto internos de la organización como invitados externos— carguen y validen información.

A continuación, se presenta un detalle explicativo de sus funcionalidades y características clave:

Estructura y Organización del Lienzo

El maquetador se conforma por dos pestañas: Formulario (construcción del formulario) y Estilos (configuración del estilo a aplicar al formulario).

Formulario

Esta pantalla cuenta con las siguientes secciones:

• Añadir: lista de campos (widgets) disponibles.

• Editar: una vez que el campo es arrastrado al panel derecho, se habilita esta solapa para poder realizar la configuración.

Los diferentes campos de carga (widgets) se organizan mediante contenedores, los controles de los contenedores aparecen una vez que se arrastró el primer campo:

• Columnas: Cada contenedor puede configurarse en una o varias columnas para distribuir los widgets visualmente.

• Duplicar y Eliminar: Es posible replicar exactamente un contenedor completo con un solo clic (botón de copiar) o eliminarlo de forma directa con el icono del tacho de basura.

  

• Paginado (“Dividir formulario en pasos”): El diseñador puede activar esta opción para que cada contenedor del lienzo se comporte como una página individual. Al usuario final se le presentará un formulario paginado con botones para avanzar paso a paso. Si esta opción se desactiva, todo el contenido se mostrará de corrido en una sola página con desplazamiento vertical (scroll).

• Visualización responsive: se puede ir diseñando el formulario y ver como se visualiza en diferentes resoluciones. El maquetador incluye una botonera superior que permite alternar la vista previa entre PC/Escritorio, Tablet y Teléfono móvil.

• Vista previa: al hacer clic se visualiza el resultado final del formulario (como lo visualizará quien lo complete). Ej: En caso de querer ver cómo se visualizará el formulario en un teléfono móvil y con división en pasos. Para volver a seguir editando se debe hacer clic en el botón “Volver a editar”.

Configuración y Propiedades de los Widgets

Al seleccionar cualquier elemento arrastrado, se habilita la pestaña de edición para ajustar sus propiedades individuales:

• Campo Requerido (Obligatorio): Si se activa esta propiedad, el usuario final no podrá completar el formulario ni avanzar en el proceso hasta que el campo contenga datos (el botón de continuar permanecerá bloqueado).

• Solo Lectura: Permite mostrar información fija o precalculada que el usuario no podrá editar, útil en etapas de validación o control.

• Título y Textos de Ayuda: Se puede activar o desactivar el título del widget, definir una descripción explicativa en la parte inferior y configurar un placeholder (texto indicativo gris dentro del campo).

• Guardar en Atributo (Persistencia de Datos): Todo dato que se requiera utilizar en etapas posteriores del proceso debe guardarse en un atributo. El maquetador asiste al usuario filtrando y forzando que el tipo de atributo coincida exactamente con la naturaleza del widget (por ejemplo, el widget de número solo permite guardar o crear atributos numéricos).

Tipos de Widgets Disponibles

El maquetador cuenta con una paleta diversa de elementos para capturar diferentes tipos de datos:

• Campos de Texto: Para cadenas generales (línea simple) o bloques extensos (TextArea).

• Números y Fechas: Campos validados para valores numéricos, fechas o fecha y hora, que incluyen funcionalidades avanzadas como fechas relativas (por ejemplo, definir por defecto “hoy menos 2 días”).

• Selectores de Opciones:

  • Checkbox y Radio Button: Para selecciones múltiples o exclusivas.

En el caso de Radio Button, se puede editar las opciones (1) y valor (2) que se guardará cuando se seleccionen.

• Selector: Desplegables que pueden cargarse de forma estática (escribiendo clave-valor a mano) o de forma dinámica (realizando consultas automatizadas a un diccionario de datos o API).

En el caso de seleccionar que sea dinámico, se puede indicar si se requiere utilizar datos del Diccionario de Datos de Finnegans o no.

Una vez seleccionado el maestro, se deben obtener los datos para poder indicar qué dato es el que se va a mostrar “dato a mostrar” como opción del selector y cual es el dato que se guardará “dato a guardar”.

• Subida de Archivos: Permite al usuario adjuntar documentos que se guardarán en un atributo de tipo archivo.

• Grillas (Tablas): Tablas interactivas basadas en estructuras JSON para que el usuario complete filas y columnas. Para poder configurar un widget grilla lo primero que se debe hacer es tener la estructura en un atributo tipo JSON. Esta estructura ya puede tener datos o simplemente plantear una estructura de grilla vacía que se completará en el momento de ejecución del caso.

Una vez que se selecciona el atributo desde donde se va a tomar la estructura y donde luego de la ejecución se guardan los valores, se puede configurar como se visualizará la grilla en el momento de ejecución.

Una vez que selecciono la estructura que me interesa en este caso las “filas”, puedo comentar a ajustar las columnas.

En el caso que el diseño requiera que una de las columnas de la grilla sea editable y los datos se ingresen en el momento de ejecución del caso, se debe tildar el check de “Permite edición” e indicar el tipo de dato que permite la celda.

Nota: en el caso de requerir que la celda ofrezca opciones se puede elegir la opción “Selector” y tendrá el mismo tratamiento que el widget Selector visto anteriormente

• Descripción: Textos enriquecidos con alineación que funcionan como separadores estéticos.

• Envío de Link: enlaces cliqueables hacia URLs externas.

Importante: se aplica la misma distribución de columnas en todos los dispositivos (no reorganiza de manera responsiva automática las columnas múltiples a una sola en pantallas pequeñas). Por lo tanto, si se pretende que los usuarios completen el formulario desde dispositivos móviles, la recomendación oficial es diseñar siempre los contenedores utilizando una sola columna para garantizar que los campos no se deformen ni se vuelvan ilegibles en celulares.