Saltar al contenido principal

Rechaza automáticamente solicitudes sin verificación de identidad

Rechaza automáticamente solicitudes sin verificación de identidad

Usa este workflow para rechazar automáticamente una solicitud de ejercicio de derechos (DSR) cuando el titular no completa la verificación de identidad dentro de un plazo definido, por ejemplo 7 días. El titular recibe un correo con la resolución y el rechazo queda registrado con su razón para fines de auditoría.

Cómo funciona​

El flujo combina cinco bloques:

  1. Evento generado — inicia una ejecución cada vez que se crea una solicitud (data_subject_request.created).
  2. Espera — pausa la ejecución durante el plazo definido.
  3. Enviar solicitud HTTP — cumplido el plazo, vuelve a consultar el estado de la solicitud. Es necesario porque el contexto de la ejecución conserva el estado capturado cuando se creó la solicitud y no se actualiza solo porque el titular verificó su identidad mientras el workflow esperaba.
  4. Filtro — evalúa el estado recién consultado. Si la identidad ya fue verificada, la ejecución termina sin hacer nada.
  5. Transición DSR — si la solicitud sigue esperando verificación, la resuelve como rechazada y notifica al titular.

Paso a paso​

1. Crea el workflow​

Entra al módulo de workflows del dashboard y crea un nuevo workflow en draft. Define un nombre y una descripción operativa, por ejemplo: "Rechazo automático de DSR sin verificación de identidad (7 días)".

2. Configura el trigger​

Agrega un bloque Evento generado como trigger inicial con el evento:

data_subject_request.created

Este evento se emite cada vez que un titular crea una solicitud de derechos. En ese momento la solicitud queda en estado awaiting_verification.

3. Agrega la espera​

Conecta un bloque Espera con el plazo que definas para la verificación. Para 7 días:

PlazoMinutos
1 día1440
3 días4320
7 días10080

4. Verifica el estado actual de la solicitud​

El contexto data_subject_request de la ejecución conserva el estado que tenía la solicitud cuando se creó (awaiting_verification) y no se actualiza automáticamente aunque el titular verifique su identidad mientras el workflow espera. Por eso el flujo necesita volver a consultar el estado antes de decidir si rechaza la solicitud; de lo contrario, siempre continuaría al paso de rechazo.

Conecta un bloque Enviar solicitud HTTP con:

  • Método: GET

  • URL:

    https://sandbox.soyio.id/api/v1/data_subject_requests/by_identifier/{{data_subject_request.humanized_identifier}}

    Este endpoint es público (no requiere autenticación) y solo expone datos no sensibles. Al publicar en producción, cambia el dominio a app.soyio.id.

  • Extracciones de respuesta: agrega una con Ruta en respuesta data_subject_request.status, Variable destino status y Tipo string, marcada como requerida.

5. Agrega el filtro​

Conecta un bloque Filtro con la siguiente expresión, que usa el estado obtenido en el paso anterior en lugar del estado capturado al crear la solicitud:

http_requests.check-status-1.parsed.status == "awaiting_verification"

Si el titular verificó su identidad durante la espera (estado validating, processing o resolved), la condición no se cumple y la ejecución termina sin rechazar la solicitud.

6. Agrega la transición de rechazo​

Conecta un bloque Transición DSR con:

  • Acción: resolve

  • Estado terminal: rejected

  • Razón de rechazo: texto que queda registrado en la solicitud. Por ejemplo:

    Solicitud rechazada: la identidad del titular no fue verificada dentro de los 7 días desde la creación de la solicitud.

  • Contenido del correo: cuerpo del correo de resolución que recibe el titular. Por ejemplo:

    Hola,

    Tu solicitud de ejercicio de derechos fue rechazada porque no se completó la verificación de identidad requerida.

    Si deseas ejercer tus derechos, puedes crear una nueva solicitud y completar la verificación de identidad.

    Saludos,
    Equipo de Privacidad

Si dejas el contenido del correo vacío, la solicitud se rechaza igualmente pero el titular no recibe la notificación de resolución. Complétalo siempre que quieras notificar el rechazo.

7. Publica​

Revisa que no queden ramas sin conectar y publica el workflow. En el dashboard verás su estado como Live.

Prueba el flujo​

Prueba ambos caminos en sandbox antes de publicar en producción. Para acelerar la prueba, reduce temporalmente la espera a 1 minuto.

Caso rechazo — crea una solicitud vía API o Privacy Center y no valides la identidad:

  1. La solicitud queda en awaiting_verification y llega el correo de recepción.
  2. Cumplido el plazo, el workflow la resuelve: status: resolved, terminal_state: rejected, con la razón de rechazo registrada.
  3. El titular recibe el correo "Solicitud rechazada" con el contenido configurado.

Caso verificado — crea una solicitud y valida la identidad dentro del plazo:

  1. Cumplido el plazo, el bloque Enviar solicitud HTTP consulta el estado actual de la solicitud y el filtro lo evalúa (processing u otro distinto de awaiting_verification).
  2. La ejecución termina sin ejecutar la transición: la solicitud no se modifica y no se envía ningún correo de rechazo.

Puedes revisar el detalle de cada ejecución, incluidos los resultados por bloque (incluida la respuesta de Enviar solicitud HTTP), en la pestaña de ejecuciones del editor del workflow.

¿Usas un agente de IA?​

Si conectaste el MCP de Soyio a tu agente (Claude, Cursor u otro cliente MCP), puedes crear este workflow con un prompt como:

Crea en sandbox un workflow que rechace automáticamente una solicitud de
derecho si pasados 7 días no se ha verificado la identidad del titular.
Notifica el rechazo por correo al titular y déjalo en borrador.

El agente usa la herramienta soyio_create_workflow con un payload como este:

Payload de soyio_create_workflow
{
  "name": "Rechazo automático de DSR sin verificación de identidad (7 días)",
  "description": "Al crearse una solicitud de derechos, espera 7 días; si la identidad sigue sin verificarse, la rechaza automáticamente.",
  "starting_step_id": "trigger-1",
  "steps_attributes": [
    {
      "id": "trigger-1",
      "_type": "EventTriggerBlock",
      "event_name_pattern": "data_subject_request.created",
      "next_step_id": "delay-1"
    },
    {
      "id": "delay-1",
      "_type": "DelayedActionBlock",
      "delay_minutes": 10080,
      "next_step_id": "check-status-1"
    },
    {
      "id": "check-status-1",
      "_type": "HttpRequestActionBlock",
      "method": "GET",
      "url": "https://sandbox.soyio.id/api/v1/data_subject_requests/by_identifier/{{data_subject_request.humanized_identifier}}",
      "response_extractors": [
        { "path": "data_subject_request.status", "key": "status", "type": "string", "required": true }
      ],
      "next_step_id": "filter-1"
    },
    {
      "id": "filter-1",
      "_type": "FilterBlock",
      "next_step_id": "reject-1",
      "condition_attributes": {
        "expression": "http_requests.check-status-1.parsed.status == \"awaiting_verification\""
      }
    },
    {
      "id": "reject-1",
      "_type": "DsrStateTransitionActionBlock",
      "action": "resolve",
      "terminal_state": "rejected",
      "rejection_reason_template": "Solicitud rechazada: la identidad del titular no fue verificada dentro de los 7 días desde la creación de la solicitud.",
      "email_content_template": "Hola,\n\nTu solicitud de ejercicio de derechos fue rechazada porque no se completó la verificación de identidad requerida.\n\nSi deseas ejercer tus derechos, puedes crear una nueva solicitud y completar la verificación de identidad.\n\nSaludos,\nEquipo de Privacidad"
    }
  ]
}

Toma en cuenta:

  • Los id de los pasos pueden ser identificadores generados por el cliente; sirven para conectar el grafo (starting_step_id, next_step_id).
  • El bloque HttpRequestActionBlock es necesario porque el contexto del workflow no se actualiza solo porque el titular verificó su identidad; sin él, el filtro seguiría viendo el estado awaiting_verification capturado al crear la solicitud. Cada response_extractors queda disponible en el contexto bajo http_requests.<id>.parsed.<key>.
  • En un FilterBlock, la condición va en condition_attributes.expression y el destino en el next_step_id del bloque. En un ConditionBlock, cada condición va en conditions_attributes y el destino de la rama verdadera va en el step_id de la condición; la rama falsa, en else_step_id.
  • Los bloques de condición y filtro deben quedar conectados dentro del grafo en la misma llamada; un bloque sin conexiones falla la validación.
  • El workflow se crea en draft. Para activarlo, el agente puede usar soyio_publish_workflow cuando lo confirmes.
  • También puedes pedirle al agente que pruebe el flujo: crear una solicitud con soyio_create_data_subject_request y revisar el resultado con soyio_get_data_subject_request y soyio_get_workflow_run.

Consideraciones​

  • Usa el workflow cuando quieras un rechazo formal con razón registrada y correo de resolución.
  • El rechazo queda trazado en la solicitud (rejection_reason, workflow_run_id) y en el historial de la ejecución.
  • Las ejecuciones en curso usan la versión del workflow con la que comenzaron; los cambios que publiques aplican solo a solicitudes nuevas.
  • No omitas el bloque Enviar solicitud HTTP: el contexto de la ejecución no se refresca solo, así que sin ese paso el filtro seguiría evaluando el estado que tenía la solicitud al crearse y rechazaría también solicitudes ya verificadas.

Referencias útiles​