Saltar al contenido principal

Cómo funciona

Cómo funciona

Un formulario de consentimiento es una capa sobre el módulo de consentimiento. Reutiliza las mismas plantillas, los mismos action_tokens y los mismos Agreements, pero agrega tres piezas:

  1. La definición del formulario (ConsentForm): campos, selección de plantillas, apariencia y pantalla de éxito.
  2. La página alojada o el iframe que renderiza el formulario y captura los action_tokens por cada consentimiento aceptado.
  3. El registro (ConsentFormEntry): los datos de los campos quedan asociados al ConsentAction o ConsentCommit resultante.

Modelo de datos​

Un consent_form agrupa todo lo que necesita el formulario alojado: la definición de los campos a capturar, los consent_templates que el usuario debe aceptar, las opciones de apariencia y la pantalla de éxito. Cada cambio publicado crea una nueva versión inmutable y conserva las anteriores.

  • consent_form: la configuración versionada del formulario.
    • fields: lista de campos a capturar (key, label, type, required, options, page_index, position).
    • consent_templates: selección de plantillas que el usuario debe aceptar (cada una con su versión y un flag required).
    • appearance: overrides de marca (hide_logo, primary_color, button_alignment, etc.).
    • success_screen: copy del estado de éxito y URL de redirección opcional.
  • consent_form_entry: un registro enviado. Guarda los datos crudos en data, el subject (Entity o Identity) y la versión del form firmada.
  • consent_action / consent_commit: la acción de consentimiento generada al enviar. Es la misma estructura que documenta la guía de captura.

Cada registro persiste el consent_form_version que firmó el usuario. Aunque luego edites el formulario, los registros viejos siguen mostrando la versión exacta que se firmó.

Ciclo de vida​

  1. Configuras el formulario en el dashboard o por API.
  2. Lo publicas. Solo los formularios publicados pueden recibir registros.
  3. El usuario completa el formulario por uno de los canales (link, iframe, API).
  4. Cada checkbox de consentimiento genera un action_token (igual que en el módulo de consentimiento regular).
  5. Al hacer submit, Soyio:
    • Crea (o recupera) la Entity del subject.
    • Persiste el ConsentFormEntry con los datos del formulario.
    • Crea un ConsentAction si solo hay un consentimiento, o un ConsentCommit si hay varios.
    • Actualiza el Agreement del usuario automáticamente.
  6. Opcional: si tu backend logra identificar al usuario con los datos recién capturados, puedes fusionar la Entity del registro en el sujeto preexistente para centralizar sus permisos.

Relación con el resto del módulo de consentimiento​

  • Las plantillas son las mismas que ya usas en el módulo de consentimiento regular. Una plantilla puede vivir tanto en un formulario como en un checkbox embebido sin duplicación.
  • La trazabilidad (Evidence) se genera con la misma estructura que para cualquier ConsentAction. Revisa la guía de trazabilidad para ver qué metadatos se persisten.
  • El estado de cumplimiento (ComplianceStatus) se consulta igual que para cualquier consentimiento. Lee la guía de consulta.
  • Las revocaciones también funcionan de forma transparente vía el Privacy Center o la API.

Versionado​

Cada vez que editas un formulario, Soyio crea una nueva versión. El comportamiento es similar al de los consent templates:

  • Los registros antiguos siguen ligados a la versión que firmaron.
  • El embed siempre sirve la última versión publicada, salvo que especifiques una versión exacta vía API.
  • El historial completo está disponible en GET /api/v1/consent_forms/{id}/versions.

Cambiar las plantillas de consentimiento de un formulario publicado equivale a pedir un consentimiento distinto. Si tu base de datos tenía registros contra la versión anterior, considera si necesitas re-solicitar el consentimiento o si la nueva versión sigue siendo compatible.

Próximos pasos​