Docs

Consola: propósitos y centro de preferencias

Editor de cláusulas versionadas y editor del centro de preferencias.

Editor de propósitos

New purpose → key (snake_case) y categoría. Opcionalmente, una etiqueta de versión y forzar el idioma.
Pestaña Draft text → uno o más idiomas (título, cuerpo y enlace opcional).
El botón de la fila indica Add text (nada publicado) → New version (versión activa, sin ediciones) → Edit draft (ediciones sin guardar). La columna Unpublished indica up to date o draft edits.
Publish → elige Display-only o Requires re-consent, una etiqueta opcional y la fecha efectiva.

Detalle completo y ejemplos en Cláusulas de consentimiento y versionado.

Un propósito siempre tiene un borrador editable abierto: al publicar una versión se abre uno nuevo, con los textos copiados. Por eso, al listar propósitos (consola, API de administración o MCP), hasDraft: true con pendingChanges: false es el estado normal: significa «hay un borrador y es idéntico a la versión publicada». Solo pendingChanges: true indica que hay ediciones sin publicar, y publicar un borrador idéntico se rechaza con Nothing to publish.

Base legal y estado por defecto

Cada propósito tiene una base legal (CONSENT, LEGITIMATE_INTEREST, CONTRACT, LEGAL_OBLIGATION, VITAL_INTEREST o PUBLIC_TASK) y un estado por defecto (NOT_GIVEN, GRANTED o DENIED), que es lo que lee una persona sin ningún registro para él. Son ajustes independientes: el estado por defecto no se deriva de la base legal, y ninguno de los dos cambia los valores que puede tomar el state de un registro. Configura cada uno de forma deliberada. Para cargar contactos que tienes bajo una base distinta del consentimiento, consulta Registrar y consultar el consentimiento.

Reglas de dependencia

Las reglas cambian qué pregunta el banner a continuación según lo que haya respondido la persona: “si acepta el correo de marketing, pregúntale también con qué frecuencia”. Se ejecutan en el navegador mientras se rellena el formulario; nunca bloquean ni alteran un consentimiento guardado.

La pestaña Dependency rules tiene un editor visual: cada regla se lee como Cuando [propósito] es / no es [granted | denied | sin responder]… Entonces [requerir | mostrar | ocultar | hacer opcional] [estos propósitos o campos]. Bajo cada regla, una frase en lenguaje natural muestra qué hará. Hay una pestaña Advanced (JSON) para la lógica que el editor visual no puede expresar (AND/OR anidados, varios efectos).

Qué quieres	Regla
Preguntar la frecuencia de correo solo si ha aceptado el correo	Cuando `marketing_email` es granted → requerir `email_frequency`
Ocultar el selector de “temas” salvo que haya dicho que sí a marketing	Cuando `marketing` no es granted → ocultar `marketing_topics`
Obligar a elegir sobre analytics antes de continuar	Cuando `analytics` es sin responder → requerir `analytics`

La mayoría de los sitios no necesita reglas de dependencia. Añade una solo cuando una respuesta deba cambiar realmente qué más se pregunta.

Centro de preferencias

Se construye desde tres pestañas. Channels (email, SMS, push…) y Topics (newsletter, novedades de producto…) son, cada una, una lista simple con etiqueta. Center las combina: una fila por canal × tema, con un interruptor required. Fields añade extras tipados (BOOLEAN, SINGLE_SELECT, MULTI_SELECT, SCALE) con opciones. Publish congela una versión; el SDK la lee desde GET /v1/preference-template.