Inscribe un predio, abre la carpeta del inmueble y la une al propietario. Si es empresa, también al expediente jurídico.
ACH
6 · Borrador
8
Ningún trámite coincide con el filtro.
Nodos
Catálogo de los nodos que se colocan en el canvas del Builder.
En el Builder SDT cada paso del flujo es un nodo. Usted le pone un nombre en el canvas; el tipo es lo que hace. El tipo no se cambia a mitad de la solicitud.
El sistema ejecuta un nodo, termina y dispara el siguiente. Si el nodo es de persona, espera. Si es automático, avanza.
Haga clic en una pieza para ver el detalle, la captura de configuración del Builder (cuando existe) y abrir la ficha.
Builder SDTPaleta de nodos · mapa de conocimiento
Inicio y cierre
Captura y espera
Decisiones
Consultas
Documentos
Cálculo
Paralelo
Expediente y personas
Comunicación y cierre institucional
Ningún nodo coincide con la búsqueda.
El nombre que usted pone en el canvas es de esta institución (por ejemplo «Datos de la solicitud»). El tipo es lo que hace el nodo. No mezcle un Expediente que crea con uno que vincula propietarios: son dos nodos.
El SDT centraliza la administración y la ejecución de trámites institucionales. La institución arma el trámite una vez. Las personas lo recorren cada vez que lo piden.
La plataforma tiene dos caras oficiales. El Dashboard SDT es el administrador: usuarios internos diseñan procesos y flujos, atienden solicitudes y configuran la institución. El Website SDT es el portal externo: el usuario externo inicia, corrige y da seguimiento.
Tres espacios que no se deben mezclar:
Website SDT — entra quien solicita (titular o persona asociada).
Dashboard SDT — entra quien opera (analista, supervisor u otro rol interno).
Builder SDT — el canvas del constructor, donde se dibuja el flujo con nodos.
Un trámite no es un programa aparte. Es un proceso con uno o más flujos publicados. Cada vez que alguien lo pide, nace una solicitud que recorre ese plano.
Lo que se publica (el proceso y su flujo) se reutiliza. Lo que avanza, espera o se cierra es la solicitud. Lo que permanece entre trámites es el expediente: la carpeta del asunto.
El SDT no es un trámite. Es la plataforma donde viven los trámites de la institución.
En el Website SDT se inician las solicitudes. El glosario del administrador llama así al portal de trámites: entra el usuario externo. El equipo interno no opera desde aquí: ve esas mismas solicitudes en el Dashboard SDT.
Cuando el flujo llega a un formulario, el portal muestra esa tarea a la persona. El recorrido se detiene hasta que envía. Al enviar, el sistema retoma el plano en la pieza siguiente.
Si hay representación, la persona asociada entra al portal a nombre del titular. La solicitud sigue siendo del titular.
En Trámites hay dos pestañas. Mis trámites lista lo que ya inició: nombre, número, estatus, última actualización y fecha de ingreso. Si no hay nada, el mensaje es «Aún no tienes trámites en proceso», con el botón Nuevo trámite. Lista de trámites es el catálogo de la institución: etiqueta, nombre, descripción y Ver detalle.
En el detalle, antes de iniciar, se ven descripción, costo aproximado, tiempo, pasos, requisitos y trámites previos. Iniciar trámite arranca la solicitud.
Los estatus más habituales en la lista son Pendiente (falta una acción suya o del sistema), En proceso y Completada. El texto del globo lo configura la institución.
El Builder SDT es el módulo donde se diseñan, configuran y administran los flujos. El área gráfica es el canvas: ahí se colocan y conectan nodos.
Un cambio de recorrido no pide un desarrollo aparte: se cambia el flujo, se valida, se aprueba y se publica una versión.
Cada nodo hace una sola cosa. Un Expediente crea la carpeta, o vincula propietarios, o une carpetas; no las tres a la vez. Un Condicional If solo elige rama. Un formulario solo captura y espera.
El tablero es la pantalla Inicio del Dashboard SDT. Presenta métricas e indicadores. Sirve para supervisar volúmenes. No sirve para resolver una solicitud concreta: eso se hace en el detalle de la solicitud.
Tras un ingreso correcto, el sistema abre Inicio. Arriba están el título, el buscador «Buscar…» y la campana de notificaciones (punto azul si hay avisos sin leer).
El contenido, de arriba abajo:
Saludo según la hora y la línea «Visualice las últimas actualizaciones de su institución».
Métricas — enlace Actualizar y tres tarjetas: Procesos, Flujos y Trámites.
Trámites — Actualizar y tres tarjetas: Solicitudes en proceso, resueltas y pendientes.
Tabla de solicitudes — pestañas Normales, Express y Mis firmas; buscador «Buscar solicitud…» y Filtros. Columnas: nombre del trámite, estado (fase y subestado) y tiempo transcurrido. Cada fila abre el detalle. Mis firmas muestra las que esperan su firma.
Administración — Roles, Usuarios (internos, externos y grupos), Calendario, Portal (avisos del sistema, preguntas frecuentes, plazos de suspensión, pagos NPE).
Las métricas son indicadores cuantitativos: cuántos trámites se crearon y cuántas solicitudes están en proceso, resueltas o pendientes. Describen el conjunto, no el caso.
Usted las consulta en Inicio. El bloque Métricas cuenta procesos, flujos y trámites publicados. El bloque Trámites cuenta solicitudes en proceso, resueltas y pendientes. Un enlace Actualizar refresca los contadores.
Un cambio de estado en una solicitud se refleja en esas cifras cuando el sistema registra el cierre. Si el rol no tiene permiso de métricas, esas tarjetas no aparecen o no se actualizan.
En el administrador, Recursos → Plantillas. Ahí se crean, editan, versionan y activan o desactivan las plantillas que luego usa un nodo.
Sirven para el generador de documentos y para notificaciones (correo o SMS). El nodo no escribe el texto a mano cada vez: toma una plantilla activa e inserta variables del flujo.
La página principal lista plantillas con búsqueda, ordenamiento y filtros. Puede crear una, editar el contenido en el editor (barra de formato), insertar variables, consultar versiones, ver el detalle y activarla o desactivarla.
Una plantilla inactiva no debe usarse en un flujo publicado. Cambiar el contenido crea una versión nueva; las solicitudes ya abiertas siguen el plano con el que nacieron.
Editar una plantilla no cambia por sí sola el orden del flujo. Quien usa el texto es el nodo que la apunta.
En el administrador, Administración → Calendario. Ahí se configura el año fiscal, se consultan días y se crean eventos.
Un evento puede ser de un día o de un rango, repetirse y, si es bloqueante, cambiar el día hábil. Eso afecta prórroga y suspensión de plazo: el reloj cuenta días hábiles según este calendario, no según el almanaque civil a secas.
Puede marcar días, ver el detalle de un día, crear un evento (tipo, fecha o rango, frecuencia) y definir si el evento es bloqueante.
Los plazos de suspensión institucionales también se configuran en Administración → Portal (plazos de suspensión). El calendario y esos plazos no se mezclan: uno dice qué días corren; el otro, cuánto se puede suspender.
Marta no “pausa” un expediente a mano en el calendario. El calendario solo dice qué días cuentan.
El ambiente de aceptación sirve para comprobar que el sistema funciona antes de producción. No es el ambiente diario de operación ni el de pruebas internas de construcción.
Cada institución tiene sus propias direcciones de pruebas y de aceptación. Un trámite en borrador se recorre ahí para ver si el plano hace lo que se espera: esperas, cierres y carpetas.
El inicio de sesión es común a la plataforma (administrador) y al portal. Usted escribe usuario o correo y contraseña, y pulsa Iniciar sesión. Un ingreso correcto envía un correo con fecha, hora y dirección del acceso, y pide un código de un solo uso al correo.
En el administrador, Recordar usuario guarda el nombre para la próxima vez. No guarda la contraseña.
Quien aún no tiene cuenta en el Website SDT se registra: el sistema verifica el correo y pide una contraseña de al menos doce caracteres, con mayúsculas, minúsculas, un número y un carácter especial. Luego completa persona natural (documento y teléfono) o persona jurídica (NIT, nombre y teléfono) y acepta los términos. Puede diferir esos datos con Realizar más tarde y cerrar sesión.
El primer acceso de un usuario interno es distinto: un administrador crea la cuenta en el Dashboard SDT. El sistema envía un correo para que esa persona establezca la contraseña. Recién entonces puede entrar con correo y clave, y el código de un solo uso.
Recuperar contraseña envía un enlace único al correo. El enlace vale quince minutos; pasado ese tiempo, pida otro. La nueva clave cumple las mismas reglas y no puede repetir ninguna de las seis anteriores. Al restablecer, la sesión se abre sola.
Cierre por inactividad: a los quince minutos sin actividad aparece un aviso con cuenta regresiva. Continuar mantiene la sesión. Si no confirma, se cierra. Al volver a entrar, el sistema lo lleva al mismo lugar.
Después de una clave correcta, el sistema genera un código temporal y lo envía al correo registrado. Escríbalo en la pantalla de validación para abrir el tablero.
El código confirma que quien tiene la clave también tiene el correo. No se guarda para el siguiente ingreso: cada vez se genera otro. La pantalla dice que se envió un código para verificar la identidad. Si las credenciales fallan y el correo existe, llega además un aviso del intento, distinto del código.
El usuario interno está autorizado para el administrador: consulta, revisa, da seguimiento o administra, según su rol. Pertenece a uno o más grupos. El grupo influye en qué solicitudes ve; el rol, en qué acciones puede ejecutar.
No inicia trámites en el portal. Eso lo hace el solicitante. Una solicitud de Ana aparece en el administrador para que Marta la atienda; Marta no “pide” esa inscripción en lugar de Ana.
El solicitante es la persona o empresa que inicia la solicitud. Puede ser el titular del asunto o una persona asociada que lo representa.
Se administra como usuario externo: alta, cambio, activación y restablecimiento de clave, si el rol del interno lo permite. En expedientes, esa misma persona puede quedar como propietaria de una carpeta; eso es vincular propietario, no «ser solicitante».
En Mi perfil del portal, los datos del documento (nombres, documento, fecha de nacimiento) no se editan: formaron parte del registro. Sí se ven correo, teléfono, cambio de contraseña y el indicador de infracciones (libre de multas e insolvencias, o el aviso en rojo). Una multa pendiente también avisa al intentar un trámite.
No es usuario interno. No entra al administrador. Una solicitud suya sí aparece ahí para revisión.
El rol indica qué puede hacer el usuario interno en el administrador. Analista, técnico, líder o supervisor son ejemplos. Cada institución define los suyos.
De un rol se consulta la descripción, los permisos, las personas asignadas y el historial.
Hay otra familia de roles, distinta: los roles de un expediente (quién consulta o actúa sobre una carpeta). Esos los define la entidad del expediente. No sustituyen al rol del administrador.
Un grupo sirve para asignar trabajo y permisos en bloque, no de uno en uno.
Se puede crear, editar, activar o desactivar. Quién ve qué solicitudes puede depender del grupo, no solo de la persona. En una revisión con varios grupos, cada grupo puede completar su parte del ciclo antes de que el flujo avance.
No es un rol. El rol dice qué acciones existen. El grupo dice con quién se comparte el trabajo.
Alta, edición, activación, desactivación y restablecimiento de clave son operaciones de esta gestión. La clave nueva pide al menos doce caracteres, mayúsculas, minúsculas, número y carácter especial, y no puede repetir las seis anteriores.
El proceso es el contenedor del trámite en el Dashboard SDT: nombre, etiqueta, descripción y, si aplica, ficha técnica. De él cuelgan uno o más flujos.
La persona no abre un proceso: presenta una solicitud. Varias solicitudes pueden estar a la vez sobre el mismo proceso, cada una en una etapa distinta.
En Recursos → Procesos el listado muestra búsqueda, filtros, estado, versión del flujo vigente y el menú de acciones. Nuevo proceso registra el contenedor; el trámite no está completo hasta que hay un flujo publicado.
En el administrador, Recursos → Procesos, pestaña Etiquetas. Sirven para clasificar procesos y reconocerlos en listados y en el Website SDT.
Crear, editar, activar, desactivar o eliminar una etiqueta no modifica por sí mismo cómo corre un flujo. Solo organiza. Una etiqueta inactiva deja de ofrecerse al crear o clasificar procesos.
El listado muestra nombre, cuántos procesos la usan, estatus y acciones. Nueva etiqueta pide nombre, descripción, estado e imagen opcional. Puede buscar por nombre y filtrar por estado.
Al crear un proceso se asocia una etiqueta de clasificación. En el detalle de una solicitud esa etiqueta aparece como dato de contexto, no como un paso.
Una etiqueta no es un trámite ni un nodo. Es una clasificación del proceso.
El flujo es la secuencia de nodos del trámite. Se arma en el Builder SDT, dentro del detalle del proceso. Cada solicitud recorre la versión publicada con la que nació.
El sistema no se queda “pensando” en un bucle. Ejecuta un nodo, termina y dispara el siguiente. Si el nodo es de persona (formulario, pago, firma, revisión), espera. Si es automático (N8N, condicional, expediente), avanza cuando puede.
El formulario es la pieza que pide datos en el portal. El flujo no llena la pantalla: asigna la tarea a quien solicita. Esa tarea pasa de asignada a en curso y a enviada.
Mientras no se envía, la solicitud no avanza. Antes de enviar, el portal muestra una vista previa de todas las respuestas. Usted puede volver y corregir. Al confirmar, aparece «Formulario enviado» y puede regresar al detalle del trámite.
Cuando se envía, esos datos pasan a lo que sigue: una consulta, un expediente o una decisión. En una corrección, el mismo formulario se reabre. Hay un contador de tiempo (fuera y dentro del formulario) para subsanar; el plazo lo define la institución. El flujo retoma desde esa espera, no desde el inicializador.
En el administrador, quien revisa abre el mismo formulario ya enviado: filas por campo, con historial, aprobar o rechazar y comentario. Enviar remite la revisión.
No es el expediente. El formulario captura. El expediente guarda el asunto a lo largo del tiempo.
Algunos datos no viven en SDT. El nodoN8N del Builder los pide a un automatismo externo. Si llegan, el flujo continúa. Si fallan, se cierra por la rama de error. No se queda a medias en esa consulta.
El nombre lo pone quien arma el recorrido en el constructor. En operación importa qué dato entra y qué sale hacia lo que sigue. El resultado se entrega a la pieza siguiente (por ejemplo, el código de registro para crear la carpeta).
La decisión mira un dato y elige una rama. Cada etiqueta de salida la define el constructor. En la forma más simple hay dos caminos (sí o no). También puede haber varias salidas; se toma la primera que cumple.
Un caso frecuente es el tipo de persona: si el camino es natural, el flujo sigue por un lado; si es jurídica, por otro.
La decisión no vincula propietario ni une carpetas. Solo elige por dónde continuar. Tampoco “adivina” el tipo: usa el dato que ya vino del formulario o de una consulta.
El historial es la bitácora de una solicitud: cambios de estado, fechas, personas y acciones. Se puede consultar y, si el permiso lo permite, exportar.
Es la base de la trazabilidad. La auditoría es cada acción. El historial es el recorrido. Una justificación de rechazo o un visto bueno quedan aquí, no solo en un correo.
El expediente guarda un mismo asunto aunque pasen varios trámites.
Entidad · el cajón
Registro A
Registro B
Las hojas de cada carpeta son las solicitudes que la han llenado.
Figura 1. La entidad es el cajón. El registro es una carpeta. Las hojas son las solicitudes.Figura 2. Documentación → Expedientes en el administrador (captura QA).
Crear la carpeta copia datos del formulario y de consultas previas. No le pone dueño ni la une a otra. Eso se configura después, en otras piezas de Expediente.
En el administrador, Documentación → Expedientes. Se elige la entidad (con versión y si está Activa). Se listan registros; uno con infracciones muestra esa marca. Nueva entidad abre el editor: título, roles (Propietario por defecto) y secciones con campos. Guardar crea una versión nueva.
En el portal, Expedientes: selector de entidad, lista, y al abrir: pestaña Solicitudes (nombre, número, estado, quién la hizo, última actualización) y pestaña Resoluciones (documentos e historial de aprobaciones, rechazos, cancelaciones e improcedencias).
Una solicitud no es un expediente. La solicitud es una vez. El expediente es lo que queda. Si el flujo se corta entre crear y asociar, la carpeta existe sin dueño.
Crear, vincular propietarios y unir carpetas son tres operaciones. En el constructor, cada pieza de Expediente hace una.
La entidad es el tipo de expediente que define la institución. El selector lista entidades y si la última versión está Activa o en Borrador.
Ahí viven los roles que se pueden asignar a las personas de cada registro (consultar, actuar, sin ser dueñas). El dueño no es uno de esos roles: es una fila aparte.
Un flujo de Expediente apunta a una entidad. Crear un registro sin entidad no es posible: no hay cajón.
El registro es un caso concreto dentro de una entidad. Se crea a mano o cuando alguien presenta una solicitud.
Al abrirlo en el administrador: migas Expedientes › entidad › registro; pestañas Detalle e Historial; pills de campos y Ver más; identificador, número de personas y de registros asociados, última actualización. El cuerpo tiene Solicitudes y Resoluciones, cada una con buscador y filtros.
El código del registro es el que se usa para unirlo a otras carpetas o para vincular propietarios. Agregar o editar captura los campos de la entidad y permite asociar usuarios externos y otros registros.
Crear el registro no lo liga a personas ni a otras carpetas. El código que vino de una consulta identifica esta carpeta en las piezas siguientes.
Son tres vínculos del expediente. La representación es otra familia: una asociación de personas que la institución aprueba en el portal. El módulo está en Jerarquías.
En la carpeta:
Vincular propietario — dueño de esta carpeta.
Personas con rol — ligadas a esta carpeta, sin ser dueñas. Los roles se sincronizan: quedan los que manda el flujo y se quitan los demás. El dueño no se toca.
Vínculo entre registros — esta carpeta con otra, en ambos sentidos. Vincular reemplaza las uniones previas de esa carpeta. Un código que no existe se omite. No se une a sí misma.
Jerarquías no es un trámite. Es la capa del SDT que define el contexto de ejecución: quién tramita, a nombre de quién y con qué respaldo. En la operación real, quien pulsa no siempre es el titular.
Sin esta capa, una cuenta equivale a una persona y a un trámite propio. No hay forma clara de operar en nombre de otro. Se pierde el rastro entre quién ejecutó la acción y a quién representaba.
Con Jerarquías, una persona puede actuar por sí misma o en nombre de un titular autorizado. El sistema conserva las dos identidades: el ejecutor real y el titular representado.
Representación e impersonación — en el portal, alguien presenta solicitudes a nombre del titular. El vínculo es una asociación: se registra, la institución la aprueba o la rechaza, y recién entonces se puede elegir ese contexto.
Propietario — una persona queda como dueña de un expediente al vincular propietarios. Otras pueden tener un rol sobre esa carpeta sin ser dueñas.
Vínculo entre registros — esta carpeta con otra, en ambos sentidos. No asigna dueño. No es representar.
El constructor configura los flujos. Cada nodo Expediente hace una sola operación: vincular propietarios, ligar roles o unir carpetas. La representación del portal no se improvisa en esa pieza.
Si se aprueba, se persiste el vínculo, se activan los permisos, se registra el poder y se notifica. Si se rechaza, no queda representación. Si la persona destino aún no tiene cuenta, queda pendiente: el vínculo se activa cuando se registra.
La institución decide si una empresa debe verificarse antes de operar. Puede registrarse en el portal sin estar verificada. Si la verificación es obligatoria, entra pero no inicia otros trámites hasta que el trámite de verificación se apruebe. Lo mismo aplica si una persona natural intenta representar a una jurídica no verificada.
En el Dashboard SDT el selector de expedientes localiza por número de registro. En esta fase no comprueba solo si el usuario tiene derecho sobre esa carpeta: quien conoce el número exacto puede encontrarla. La legitimidad se verifica en la institución, no la da el buscador.
La trazabilidad de este módulo no es un reporte aparte. Cada acción debe poder explicarse: qué ocurrió, quién la ejecutó (persona real) y, si aplica, en nombre de quién (persona impersonada), con fecha y hora.
La representación es el vínculo formal que permite a una persona asociada actuar en nombre del titular. La solicitud queda del titular.
No sustituye al propietario ni al vínculo entre carpetas:
Vincular propietario — quién es dueño de la carpeta.
Unir registros — esta carpeta con otra, en ambos sentidos.
Representar — la asociación aprobada. Impersonar es usarla en el portal para ejecutar el trámite.
La asociación, por sí sola, no habilita representar. El vínculo se vuelve operativo cuando la institución lo aprueba. Recién entonces el selector de contexto puede listarla.
El flujo cambia si la persona destino ya tiene cuenta.
Si ya existe: se identifica al titular, se busca a la persona destino por documento, se capturan los datos de la asociación y la institución confirma o rechaza. Aprobada, se habilita la representación.
Si todavía no tiene cuenta: se pide el correo para continuar. Puede exigir respaldo documental, según el nodo. Tras la aprobación institucional queda como usuario pendiente. El vínculo se activa cuando esa persona completa el registro.
Ninguna asociación otorga representación sin una decisión explícita.
Aprobada — se persiste el vínculo, se activan permisos, se registra el poder y se notifica.
Rechazada — no se crea vínculo ni permiso.
Aprobada, sin cuenta aún — usuario pendiente; se activa al registrarse.
La vigencia del poder puede llevar fecha de vencimiento o dejarse sin término. Si está vencida, no se continúa en nombre de esa persona.
En el menú del portal, Representantes y Representaciones son dos entradas. Una lista a quién puede representar; la otra, quién lo representa a usted. Eso no aparece en el administrador como «dueño del expediente».
Qué solicitudes ve la persona asociada de una persona natural depende de lo acordado: las del titular, o solo las que ella misma inició.
Pasar esas solicitudes a otra persona es reasignación, no un cambio de dueño ni de propietario.
Elige contexto: cuenta propia o un titular asociado.
Ejecuta el trámite.
El selector muestra el contexto activo. Permite ver y elegir. No crea ni edita asociaciones.
Dos identidades, siempre separadas:
Titular — datos de la persona representada.
Ejecutor real — quien realiza la acción.
La auditoría cubre acciones con y sin impersonación. Siempre debe poder reconstruirse quién ejecutó realmente y, si aplica, en nombre de quién, con fecha y hora.
Una empresa con varios apoderados comparte la visibilidad de sus solicitudes.
Impersonar no cambia al propietario de la carpeta. Luis puede tramitar a nombre de Ana; el nodo Expediente, si vincula propietarios, deja a Ana como dueña.
Si el poder está vencido, no se continúa en nombre de esa persona. Si una persona natural intenta impersonar a una jurídica no verificada, no inicia otros trámites hasta que la verificación se apruebe. El detalle está en Jerarquías.
El propietario es la persona, natural o jurídica, dueña de un registro. En la carpeta es una fila aparte: no se mezcla con quienes tienen un rol sin ser dueños.
El rol Propietario está disponible por defecto y no es obligatorio. Puede asignarse o desasociarse desde el Dashboard SDT. Una misma persona puede tener más de un rol en el expediente.
En el constructor, un nodo Expediente con la operación vincular propietarios deja a una persona como dueña de esa carpeta. Se identifica por documento y correo. Si ya es dueña de ese registro, no se duplica el vínculo.
La marca de dueño suma: no quita a un propietario anterior. Quitar al dueño es desvincular propietarios. Desvincular usuarios sin indicar un rol también puede quitar al dueño. Si se indica un rol, solo se quita ese rol.
No crea el registro. No une dos carpetas. No es tramitar a nombre de otro: eso es representación e impersonación.
El tipo de persona (natural o jurídica) lo decide el trámite si lo necesita, con una decisión. Vincular propietario no abre por sí solo un vínculo entre carpetas.
Puede haber más de un propietario si el flujo lo vincula así. Desvincular un rol no quita al dueño. Desvincular al dueño no borra la carpeta.
El campo Expedientes de un formulario permite elegir la carpeta por número de registro. En esta fase el selector no valida solo si el usuario tiene relación o derecho sobre esa carpeta. Quien conoce el número exacto puede localizarla. La legitimidad se verifica en la institución.
La solicitud nace en el portal cuando el solicitante presenta el trámite. En el administrador se ve el estado, la etapa, los tiempos y el historial.
Varias solicitudes pueden ir llenando el mismo registro. Cada una es una vez.
Si alguien tramita a nombre del titular, la solicitud sigue siendo del titular. El flujo de esta solicitud es el plano publicado en el momento en que nació.
En el Website SDT, Mis trámites es la lista. El detalle muestra los pasos con los estados de la vista externa. En el Dashboard SDT, el detalle tiene pestañas Detalles e Historial y los estados de la vista interna.
Estados internos (resumen del manual del administrador):
El estado no es un nodo: es la condición visible de la etapa en la que está la solicitud.
En el administrador, a la izquierda: Pasos de su solicitud (nombre, fecha de inicio, estado). A la derecha: Información general (nombre del trámite, número, titular, iniciado, última actualización, etiqueta, estado e infracciones). Desde ahí se abre la revisión, la firma o los modales de gestión.
Para dejar de continuar un trámite, vea desistimiento. No está disponible cuando ya hay resolución.
En operación aparecen varios números a la vez. No son intercambiables: cada identificador de negocio nombra una cosa distinta — esta solicitud, la carpeta del asunto o un expediente que ya existía.
Tres identificadores de negocio suelen mezclarse. Elija uno para ver qué es, dónde aparece y con qué no confundirlo.
Identifica una presentación concreta: el recorrido que la persona inició en el portal. Cada nueva presentación genera otro número, aunque sea sobre el mismo inmueble o el mismo asunto.
Cuándo nace
Al iniciar el trámite (nodo Inicializador). Aparece en Mis trámites, en la bandeja del administrador y en plantillas de notificación.
Ejemplo
SOL-2026-008412
Después del cierre
Queda en el historial aunque la solicitud cierre. No se reutiliza en una segunda presentación.
Dónde suele verse
Website SDT — Lista Mis trámites y el detalle del trámite (columna número).
Dashboard SDT — Bandeja de solicitudes e Información general del detalle.
Notificaciones — Correos y avisos usan $numero_solicitud en plantillas.
No confundir con
No es el código de registro de un expediente.
No es una salida de N8N que solo valida o ramifica (valido, multas_activas, etc.).
No identifica la carpeta del asunto: identifica esta solicitud.
Identifica un registro de expediente en SDT: la carpeta donde viven documentos, historial y vínculos del asunto. Suele materializarse en un nodo Expediente; con frecuencia el código llega antes desde un N8N que lo genera o lo obtiene de un sistema externo.
Cuándo nace
Cuando el flujo crea o consolida la carpeta en Documentación → Expedientes. Puede haber más de un registro en la misma solicitud si el diseño prevé carpetas distintas (por ejemplo, un trámite nuevo sobre un predio ya registrado).
Ejemplo
REG-2026-004821
Después del cierre
La carpeta del asunto sigue existiendo al cerrar la solicitud. Una nueva presentación puede generar otro registro aunque el asunto de fondo sea el mismo.
Dónde suele verse
Nodo N8N — Construye o trae el identificador (salida codigo u otra salida de registro) hacia el Expediente.
Nodo Expediente — Usa ese identificador para crear o actualizar la carpeta. Puede devolver expedient_id hacia otros nodos.
Dashboard SDT — Documentación → Expedientes → registro. Campo identificador en la ficha.
No confundir con
No es el número de solicitud.
No es una validación de flujo (valido, multas_activas): esas salidas ramifican, no nombran la carpeta.
No confundir la carpeta creada en esta solicitud con la que la persona eligió si ya existía.
Cuando el flujo pide elegir o traer un expediente que ya está en SDT. El formulario (u otro nodo) devuelve el id de esa carpeta; el trámite opera sobre ella o la vincula con un registro nuevo, pero no la crea en ese paso.
Cuándo nace
Al capturar datos en un formulario con selector de expedientes, o cuando un nodo reutiliza el identificador de un registro previo. Común en trámites sobre inmuebles ya inscritos, proyectos derivados o asociaciones entre carpetas.
Ejemplo
REG-2024-001892 (predio o asunto previo)
Después del cierre
El registro referenciado permanece en SDT. El vínculo con la carpeta nueva del trámite queda en ambas fichas si el diseño incluye asociación.
El desistimiento interrumpe un trámite que ya no puede o no debe seguir. No es un rechazo del analista ni un cierre por error de una consulta. Lo pide quien solicita.
Se puede pedir en cualquier etapa, excepto cuando ya hay resolución: el trámite, a efectos prácticos, ya terminó. En ese caso la opción no se muestra.
El sistema avisa en dos canales: el panel de la campana (en la aplicación) y el correo. No todos los eventos usan los dos. La institución configura qué se envía en Administración → Portal → Notificaciones.
Llegan, entre otros, cuando hay observaciones en la solicitud, un pago pendiente, fallido, completado o eximido, una prórroga o suspensión otorgada o denegada, o un cambio de persona asociada. El texto concreto lo define la institución.
Una observación no llega al portal hasta el visto bueno. El aviso al solicitante es posterior a esa autorización.
Quien tiene el permiso permite el avance o el cierre dentro del flujo. En una revisión, aprobar puede ser campo por campo: si todas las correcciones del ciclo están aprobadas, la revisión queda aprobada y el flujo continúa.
Lo contrario, con justificación en el historial, es el rechazo. Aprobar no vincula propietario ni une carpetas: solo autoriza el camino que el plano ya definió.
La aprobación aparece cuando el trámite incluye una pieza de revisión. Si el plano avanza solo después del formulario, no hay aprobación de analista.
Quien tiene el permiso deja la justificación. Esa nota forma parte del historial.
Un rechazo de revisión no es lo mismo que un cierre por error de una consulta. El cierre por error lo dispara el plano cuando el otro sistema no responde. El rechazo lo dispara una persona, con motivo.
Si el trámite permite correcciones, el rechazo de campos puede devolver el formulario al solicitante. Hay un límite de ciclos: al alcanzarlo, la revisión se niega y el flujo continúa por esa rama.
El visto bueno revisa y aprueba las observaciones de una solicitud antes de enviarlas a quien solicita. En revisiones con grupo, el líder confirma el ciclo: observar no basta.
Si hace falta más tiempo para corregir, entra la prórroga. Si el reloj debe detenerse, la suspensión. El visto bueno no mueve esos relojes por sí solo: autoriza el envío de lo observado. Recién entonces el solicitante ve las observaciones en el portal y puede recibir la notificación.
La prórroga es tiempo adicional para que la persona corrija las observaciones de la revisión. El cálculo respeta días hábiles de la institución. Hay un tope: no se puede prorrogar sin límite. Se puede pedir más de una, si el trámite lo permite.
En el formulario en corrección, Solicitar plazo (arriba a la derecha) y luego Prórroga. Debe indicar:
Motivo — para que el analista decida si procede.
Documento que respalde el motivo.
Si se otorga, el tiempo se suma al contador. Llegan avisos en el portal y al correo: otorgada o denegada.
El reloj que corre hacia quien solicita (plazo externo) es el que se alarga. El reloj interno del analista es otro; no se mezclan. Solo uno está activo a la vez.
No es lo mismo que la suspensión de plazo. La prórroga alarga el plazo. La suspensión lo detiene un tiempo.
Durante ese periodo el plazo no corre. Al terminar, los días aprobados se suman al vencimiento original. Si hay varias suspensiones, la siguiente empieza cuando termina la anterior: no se solapan.
Solicitar plazo y luego Suspensión. Debe indicar motivo y documento de respaldo, igual que en la prórroga.
Si se aprueba, la solicitud pasa a Suspendido. El contador del formulario se muestra bloqueado con el tiempo concedido. Llegan avisos de otorgada o denegada. Los plazos máximos que puede pedir una persona asociada los configura la institución en Administración → Portal.
La suspensión aplica al plazo de quien corrige (plazo externo). El plazo interno del analista no se alarga con esas suspensiones.
La prórroga, en cambio, añade tiempo. No lo detiene.
La reasignación cambia quién está llevando la solicitud del titular. El trámite no se reinicia: cambia la persona que lo atiende en el portal.
Solo aplica si hay representación y el permiso lo permite. Todas las solicitudes que se muevan juntas deben ser del mismo titular. El destino tiene que estar habilitado para tomarlas (asociación activa con ese titular).
No cambia al dueño del expediente. No es vincular propietario. Es quién está sentado haciendo el trámite.
La auditoría es el registro cronológico de las acciones del sistema. Permite identificar a la persona, el momento y el elemento afectado: una solicitud, un registro, un vínculo, un ingreso.
Complementa la trazabilidad del trámite: una mira la acción; la otra, el recorrido completo. Crear una carpeta, vincular propietarios, unir registros, reasignar o representar dejan huella aquí.
Cuando hay representación, la bitácora guarda las dos identidades: quién ejecutó realmente y, si aplica, en nombre de quién, con fecha y hora.
Usted puede consultar todo el camino de un trámite: creación, cambios y resolución, con cada acción.
Se apoya en el historial y en la auditoría. Sirve para responder: en qué pieza está, qué dato pasó a la siguiente, si cerró por éxito o por error, quién intervino y, si hubo representación, en nombre de quién.
No abre ramas del flujo como la decisión. Resuelve un valor: prueba candidatos en orden y entrega el primero que tiene dato. Si falta, sigue la regla que usted configuró (error, vacío u otro comportamiento).
Sirve cuando el mismo dato puede venir del formulario, de una consulta o de un valor fijo, según el caso.
Deja el trabajo en un grupo (y, según la regla, en una persona del grupo). Quien ve la solicitud en el administrador depende de ese grupo. No cambia el dueño del expediente ni la persona asociada del portal.
Esta pieza no vincula un propietario al expediente. Arma o pide el vínculo de representación: quién tramita a nombre de quién. Puede exigir documentos. El flujo se detiene hasta que se envía en el portal.
No pregunta a nadie. Aplica operaciones (suma, texto, fechas, listas) sobre valores que ya existen. El resultado sale hacia la pieza siguiente (un monto de pago, un plazo, un código armado).
Hace falta al menos una operación configurada. Suma es un caso mínimo aparte; para casi todo use esta pieza.
Consulta tablas de referencia de la institución y entrega el registro encontrado.
DatosEn el canvas
Configuración
Figura 1. Centro de datos: pieza en el canvas y pantalla de configuración. Volver al catálogo visualFigura 2. Módulo Centro de datos en el administrador (captura QA).
En el administrador, Recursos → Centro de datos es el módulo: tablas, columnas, registros, activar o desactivar, y la pestaña Core Funcional (catálogos que el sistema pone a disposición).
En el Builder, el nodo Centro de datos opera sobre esas tablas: Leer, Crear, Actualizar o Eliminar registros. No llama a otra institución: eso es interoperabilidad. No dispara un automatismo externo: eso es N8N.
Marca el fin de esta ejecución. Puede haber varios cierres: uno por éxito y otros por error (consulta fallida, pago no hecho).
Si el trámite aún estaba en proceso, el cierre deja la solicitud como terminada. Un subflujo que cierra no termina al padre: solo termina el flujo interno; el padre retoma en la pieza siguiente al subflujo.
Como la decisión, pero con N caminos. Evalúa en orden y se queda con el primero que es verdadero. Si ninguno cumple, el constructor debe haber previsto qué ocurre (una salida por defecto, si se configuró).
El constructor indica qué automatismo llamar y qué mandar. Si llega respuesta, continúa. Si falla, cierra por la rama de error o sigue la salida que se dibujó. El nombre de la pieza lo pone quien arma el plano.
En el constructor, Expediente no es «el módulo de carpetas»: es una operación sobre un registro. Una pieza crea, otra vincula propietarios, otra une carpetas o asigna roles. No las tres a la vez.
Crear no pone dueño. Vincular propietarios no une dos carpetas. Unir es en ambos sentidos y reemplaza las uniones previas de esa operación. Un código que no existe se omite.
Abre la firma de uno o más documentos (a menudo salidos del generador). En el detalle, la lista de archivos muestra quién firmó y cuándo. El paso pasa de En proceso a Completado cuando faltan cero firmas.
En el administrador, la pestaña Mis firmas lista las que esperan a la persona interna.
El flujo no llena la pantalla: asigna la tarea a quien solicita (o a un interno, si así se configuró). La tarea pasa de asignada a en curso y a enviada.
En el Builder el nodo se arma por pasos y secciones. Cada sección tiene título, descripción y los campos que la persona debe completar. El botón Preview muestra cómo se verá antes de publicar.
Antes de enviar, el portal muestra una vista previa. Al confirmar aparece «Formulario enviado». Esos datos salen hacia la pieza siguiente.
Con Añadir campo + se elige el tipo. Cada tarjeta resume para qué sirve. Pulse una para ver, en lenguaje de administración, qué puede configurar y (si hay captura) cómo se ve en el Builder.
Toma una plantilla de la institución y la llena con campos del formulario, de consultas o de expedientes. El archivo queda ligado a esta solicitud. Suele alimentar una firma o una resolución.
Parte el plano en ramas que corren al mismo tiempo: por ejemplo, generar un documento y consultar un dato. Cada rama es independiente hasta que se juntan.
Es un envío disparado por el plano, con plantilla y destinatarios. Distinta de la campana del portal: esa campana también avisa, pero esta pieza es un paso explícito del flujo (por ejemplo, «avisar que el número ya salió»).
Genera el cobro del trámite. En el portal la persona paga con tarjeta o con NPE (número para pagar en banco). El interno ve el estado del pago (pendiente, completado, eximido) y el comprobante; no cobra en la pasarela.
El analista puede eximir. Llegan avisos de pago pendiente, fallido, completado o eximido.
Fija el resultado institucional: Aprobado, Denegado, Cancelado o Improcedente. Puede colgar un documento y un comentario opcional. En el portal, la pestaña Resoluciones del expediente lista esos archivos.
No es desistir (eso lo pide el solicitante). No es el cierre técnico del flujo, aunque suele ir cerca. Un cierre sin resolución deja el recorrido terminado sin veredicto en esa bandeja.
El plano llama a otro flujo (con su propio inicializador y su propio cierre). Mientras el interno corre, el padre espera en esta pieza. Cuando el interno termina, el padre sigue en la pieza siguiente.
El cierre del subflujo no cierra la solicitud padre.
Abre un ciclo de revisión. Quien tiene el permiso ve el formulario ya enviado, campo por campo: historial, aprobar o rechazar con comentario. Enviar remite la revisión.
Si hay correcciones, el formulario se reabre en el portal con un contador. El visto bueno autoriza que las observaciones salgan. Hay tope de ciclos: al alcanzarlo, la revisión se niega y el flujo sigue por esa rama.
Puede haber reloj interno (analista) y reloj externo (solicitante). Solo uno corre a la vez. Prórroga y suspensión actúan sobre el plazo de quien corrige.
Calificación de Lugar para modalidades CL-2 al CL-6. La persona elige un inmueble ya registrado en el formulario, completa datos del proyecto y el flujo valida vigencia y multas, genera el código de registro del proyecto vía N8N, crea la carpeta y la asocia al inmueble. Después pasan revisión técnica y legal, admisión, pago, inspección y resolución (aprobada o denegada).
Vista resumida en el diagrama; el detalle fase por fase — formularios, campos y ramas — está en la guía siguiente (extraída del JSON del constructor, v30).
Cargando diagrama…
flowchart TB
I[Inicializador] --> DC[Catálogo CL]
DC --> F[Formulario Calificación de Lugar]
F --> NV[Validación de vigencia]
NV --> NM[Multas y variables]
NM --> NR[ID de registro]
NR --> EXP[Expediente y asociación]
EXP --> RV[Revisión Integral]
RV --> ADM[Auto de admisión]
ADM --> PAG[Cobro y pago]
PAG --> INS[Inspección]
INS --> SW[Validación de Inspección]
SW --> RES[Resolución y firma]
RES --> FIN[Finalizador]
Pulse un recuadro del diagrama para ver la configuración de ese paso.
Figura 1. Fases principales. Pulse un recuadro para configuración breve de esa etapa.
Recorrido detallado del trámite. Elija una fase para ver qué se captura en formularios, qué nodos intervienen y cómo ramifica.
Avanza solo
Inicio · Número de solicitud
El inicializador abre la solicitud. A partir de aquí existe un número de trámite visible en portal y administrador.
En esta fase
Prórroga máxima configurada: 2 extensiones.
Aún no hay registro del proyecto ni inmueble referenciado.
Nodos en el constructor
Inicializador
Avanza solo
Catálogo CL · Centros de datos
Once centros de datos cargan en cadena la taxonomía CL-2 al CL-6 antes de mostrar el formulario. Precargan modalidad, submodalidad, categoría y cada uso de suelo.
Cada nodo tiene rama success y error; el error cierra con finalizador dedicado.
Lo capturado aquí alimenta listas y validaciones del formulario principal.
Nodos en el constructor
Modalidad CL
Submodalidad CL
Categoria CL
Habitacional
Alojamiento CL
Comercio Uso de Suelo
Servicios CL
Manufacturas Menores CL
Almacenamiento CL
Equipamiento CL
Centro de datos talleres
Ramas
success
Continúa al siguiente centro de datos o al formulario.
error
Finalizador de error del catálogo; no llega al formulario.
Espera a una persona
Captura principal · Formulario Calificación de Lugar
Pantalla principal del portal. La persona elige el inmueble sobre el que califica, declara usos de suelo y completa datos del proyecto. El flujo se detiene hasta el envío.
En esta fase
59 conexiones de campos salen de este formulario en el constructor.
La salida id (selector de expedientes) no crea carpeta: referencia el predio ya inscrito.
Tras el envío, un calculado registra la fecha de ingreso de solicitud.
Formulario · Formulario Calificación de Lugar
Solicitante en portal
Campo o grupo
Para qué se usa en el flujo
Inmueble / expediente referenciadoid
Validación de vigencia, validaciones de multas y solvencia, asociación al proyecto, actualización de expediente.
Uso habitacionalhabitacional_uso_de_suelo
Unificación de variables → usos_concatenados.
Uso alojamientoalojamiento_uso_de_suelo
Unificación de variables → usos_concatenados.
Uso comerciocomercio_us
Unificación de variables → usos_concatenados.
Uso serviciosservicios_us
Unificación de variables → usos_concatenados.
Manufacturas menoresmanufacturas_menores_us
Unificación de variables → usos_concatenados.
Almacenamientoalmacenamiento_us
Unificación de variables → usos_concatenados.
Equipamientoequipamiento
Unificación de variables → usos_concatenados.
Tallerestalleres
Unificación de variables → usos_concatenados.
Datos del proyecto para expediente
Varios campos alimentan Expediente Trámites Previos Aprobado (creación/actualización de la carpeta CL).
Datos para documentos de admisión
Campos hacia Formato Auto de Admisión y notificaciones de admisión.
Datos para notificaciones
Correos y avisos: resolución, multas, pago de solvencia, archivado por tiempo.
Variables tarifarias
Campo conectado a Calculo de cobro.
Planos técnicos
Campos hacia Firma Planos.
Normalización de texto
Campo hacia Convertidor de variables.
Los campos sin clave visible en el constructor comparten destino por grupo; las conexiones están en el JSON del flujo (field_id).
Nodos en el constructor
Formulario Calificación de Lugar
Fecha de ingreso de solicitud
Avanza solo
Validaciones N8N · Vigencia, multas y variables
Tras el envío avanza solo. Consultas externas y normalización preparan el terreno para el registro del proyecto.
En esta fase
Validación de vigencia usa el id del inmueble; devuelve valido (condicional If).
Convertidor de variables y Unificación de variables integran usos de suelo del formulario.
Validación de multas devuelve multas_activas; puede disparar notificación de pago solvencia.
Nodos en el constructor
Validación de vigencia
Validación
Convertidor de variables
Unificación de variables
Validación de multas
Validación de multas 1
Notificación de pago solvencia
Ramas
valido = false
Rama de no vigencia → cierre o rechazo según diseño.
multas_activas
Notificaciones de multa y decisiones por multas más adelante.
error N8N
Finalizador; la consulta externa no respondió.
Avanza solo
Registro del proyecto · Código e inmueble
El N8N ID de registro construye el código de la carpeta del proyecto. Los nodos Expediente materializan y vinculan con el inmueble referenciado.
En esta fase
Salida codigo del N8N → identificador de negocio del registro CL.
Expediente Trámites Previos Aprobado crea o consolida la carpeta.
Asociación de expediente a inmueble une proyecto ↔ predio elegido al inicio.
Actualización de expediente del proyecto sincroniza campos posteriores.
Nodos en el constructor
ID de registro
Expediente Trámites Previos Aprobado
Asociación de expediente a inmueble
Actualización de expediente del proyecto
Ramas
error codigo
Finalizador si el N8N no entrega código.
Espera a una persona
Revisión · Técnica y legal
Analistas en grupos asignados revisan la solicitud. Puede haber observaciones, interés social y revisión final antes de admitir.
En esta fase
Asignación a Grupo Revisión Técnica y Revisión Legal.
Revisión Integral: etapa humana con salidas success, error y expired.
Revisión Final cierra la etapa administrativa previa a admisión.
Formulario · Verificación de Interés Social
Analista / revisor
Campo o grupo
Para qué se usa en el flujo
Criterios de interés social
Campo conectado a Calculo de cobro (incide en tarifa).
Formulario · Formato de plantilla Aprobada / Denegada / auto de requerimiento
Analista / revisor
Campo o grupo
Para qué se usa en el flujo
Plantillas de revisión
Formularios de plantilla usados en revisión; alimentan generadores de documentos.
Nodos en el constructor
Asignar Grupo Revisión Técnica
Asignar grupo Revisión Legal
Revisión Integral
Revisión técnica 1
Revisión Final
Asignación de Grupo Revisión Final
Ramas
expired
Plazo de revisión vencido.
error
Revisión rechazada o devuelta.
Avanza solo
Admisión · Auto y notificación
Se genera el Auto de Admisión, se notifica al solicitante y puede emitirse auto de requerimiento si faltó documentación.
En esta fase
Generador Formato Auto de Admisión.
Notificación Auto de Admisión al portal.
Auto de requerimiento si la revisión lo exige.
Documentos
Formato Auto de Admisión
Auto de requerimiento
Nodos en el constructor
Formato Auto de Admisión
Notificación Auto de Admisión
Auto de requerimiento
Espera a una persona
Cobro y pago · Tarifa y solvencia
N8N calcula la tarifa; la persona paga en portal. Validaciones de solvencia adicionales revisan multas antes de continuar.
En esta fase
Calculo de cobro → tarifa_excedente hacia el nodo de pago.
Pago del trámite espera confirmación en portal.
Validación de solvencia 2 y 3 reutilizan multas_activas.
Nodos en el constructor
Calculo de cobro
Pago del trámite
Validación de solvencia 2
Validación de solvencia 3
Decisión por multas
Notificación de multa pendiente asociada a su inmueble
Ramas
sin pago
Rama error del nodo Pago.
multas activas
Notificación y posible cierre según rama.
Espera a una persona
Observaciones · Subsanación
Si la revisión dejó observaciones, se reasigna grupo y se abre formulario para que la persona subsane.
En esta fase
Asignar grupo Observaciones.
El flujo puede reabrir captura sin reiniciar desde el inicializador.
Formulario · Formulario de Observaciones
Solicitante en portal
Campo o grupo
Para qué se usa en el flujo
Respuesta a observaciones
12 conexiones en el constructor; corrige o complementa lo señalado en revisión.
Plazo sujeto a prórroga (máx. 2) y reglas de la institución.
Nodos en el constructor
Asignar grupo Observaciones
Formulario de Observaciones
Espera a una persona
Inspección · Campo y patrimonio
Equipo de inspección asignado. Se capturan resultados técnicos y patrimonio cultural en formularios dedicados.
En esta fase
Grupo de Inspección de Trámite y Asignación de técnica.
Inspección Técnica: 54 campos conectados; 33 alimentan el Switch de inspección.
Identificación de Patrimonio Cultural actualiza el expediente del proyecto.
Formulario · Inspección Técnica
Inspector en campo
Campo o grupo
Para qué se usa en el flujo
Checklist de inspección (33+ criterios)
Validación de Inspección 2 (Switch: condition_1, condition_2, condition_3, default).
Evidencias de campo
Conexiones adicionales hacia nodos de emisión favorable o desfavorable.
Formulario · Identificación de Patrimonio Cultural
La guía de recorrido (12 fases) desarrolla cada tramo. En síntesis: catálogo CL → captura y validaciones → registro del proyecto vinculado al inmueble → revisión y admisión → pago → inspección → resolución → cierre.
Catálogo de nodos en el constructor
107 nodos del flujo (sin contar los 30 finalizadores por error). Los nombres son los del
constructor; pulse el tipo para la ficha del catálogo.
Quien solicita completa el formulario. El sistema pide un número de registro, crea la carpeta del inmueble con un expediente y la relaciona con el dueño. Si el dueño es una empresa, también se une a esa persona jurídica.
El trámite arranca en el inicializador y se detiene en el formulario hasta que se envía. Después avanza solo. Si una consulta N8N falla, un finalizador cierra por esa rama; no queda a medias.
Cargando diagrama…
flowchart TB
I["Inicializador"] --> F["Inscripción del inmueble"]
F --> N1["Generador de número de registro"]
N1 -->|Si falla| X4["Finalizador · error registro"]
N1 -->|Si sale bien| E1["Generación de expediente"]
E1 --> E2["Asociación del propietario"]
E2 --> IF{"¿Persona jurídica?"}
IF -->|No| X1["Finalizador · natural"]
IF -->|Sí| N2["Obtención de persona jurídica"]
N2 -->|Si falla| X3["Finalizador · error identificador"]
N2 -->|Si sale bien| E3["Asociación a persona jurídica"]
E3 --> X2["Finalizador · jurídica"]
Pulse un recuadro del diagrama para ver la configuración de ese paso.
Figura 1. Recorrido del trámite. Pulse un recuadro para ver la configuración de ese paso. Las ramas de error cierran; no dejan la solicitud a medias.
