---
title: "¿Cómo añade a su web un formulario de contacto que escriba directamente en su CRM?"
blueprint: 013
slug: website-contact-form-into-crm
category: Captación de leads
published: 2026-09-23
revised: 2026-09-23
platform: Coevera CRM (formerly Pipeliner CRM)
canonical: https://blueprints.coevera.com/es/blueprints/website-contact-form-into-crm/
language: es
translation_of: https://blueprints.coevera.com/blueprints/website-contact-form-into-crm/
author: Lucia Schmidt
publisher: Coevera
customer_data: none
---
# ¿Cómo añade a su web un formulario de contacto que escriba directamente en su CRM?
**Respuesta corta.** **Un formulario de contacto es un formulario en línea que aloja el CRM y que
la web incrusta.** Cada definición de formulario lleva un `linkId`, y el formulario público vive
en una URL construida a partir de ese id. La página contiene esa URL y un título accesible: **sin
marcado del formulario, sin lista de campos, sin endpoint, sin clave de API**. Así, las preguntas
cambian en el CRM sin desplegar la web.
Después, haga que el envío sea un **upsert**: active `createRecordEnabled`, `updateRecordEnabled`
*y* `autolinkEnabled` juntos. Autolink compara el email enviado con el campo de email del
contacto, así que un solicitante que vuelve actualiza su propio registro en lugar de convertirse
en un segundo. En un formulario real: **49 envíos, 41 personas, nada sin coincidencia.**
El inconveniente es la medición. Un formulario incrustado no tiene destinatarios, así que **no
tiene tasa de respuesta ni lista de seguimiento**: ambas deben reconstruirse como informes sobre
los registros que ha creado.
## 01 · El problema de negocio
Todas las webs tienen uno: el formulario detrás de *Contáctenos*, *Solicite ahora*, *Solicite una
llamada*, *Regístrese aquí*. Es el mismo requisito cada vez, diga lo que diga el botón: un
desconocido escribe sus datos en una página pública, y el envío tiene que convertirse en un
registro real de inmediato. No en una notificación que alguien transcribe al CRM, ni en una fila
de una hoja de cálculo.
Lo que en la práctica significa todo esto a la vez:
- la persona se convierte en un registro que tiene **propietario**, **tipo** y un sello de su
procedencia;
- alguien que envía dos veces **no** se convierte en dos personas;
- el solicitante recibe un acuse de recibo inmediatamente;
- se avisa a la persona interna adecuada;
- se hace seguimiento a quienes empezaron y nunca terminaron;
- y marketing puede rediseñar la página, y un administrador puede añadir una pregunta, **sin que
ninguno de los dos espere al otro**.
Esa última restricción es la que hace fracasar la mayoría de las implementaciones. Un formulario
cuya lista de campos vive en el código de la web convierte cada pregunta en un despliegue, así que
el conjunto de preguntas se congela en lo que fuera el día del lanzamiento.
## 02 · Por qué falla el enfoque obvio
### Construir el formulario con la propia tecnología de la web
El reflejo es construir el formulario a mano en el framework que use el sitio y enviarlo por POST
a la API del CRM. Funciona el primer día y a partir de ahí se degrada. La lista de campos existe
ahora en dos lugares y hay que mantenerlos sincronizados a mano; añadir una pregunta es un cambio
de código, una revisión y una publicación; y la web se ha vuelto responsable de la validación, del
spam y de guardar una credencial capaz de escribir en el CRM. Cada uno de esos problemas ya lo ha
resuelto el formulario alojado.
### Un producto de formularios más un puente de automatización
Una herramienta de formularios de terceros conectada a través de una plataforma de integración
añade un salto que puede fallar sin avisar, y entrega un registro sin subtipo, sin propietario y
sin procedencia, porque el puente no conoce su modelo de datos. Después necesita un proceso de
conciliación para terminar el trabajo que debería haber hecho el formulario.
### Copiar el marcado del formulario en la página
No hay marcado que copiar. El formulario alojado es una aplicación JavaScript servida desde una
CDN estática y resuelta por su link id en tiempo de ejecución; el HTML de esa URL es un armazón de
unos 1,7 KB que contiene un único elemento personalizado. Cualquier cosa que pretenda extraer o
volver a alojar los campos del formulario no encontrará nada ahí.
### Crear un registro por envío
El error más caro es el más sencillo: activar la creación de registros y nada más. La gente vuelve
a enviar los formularios públicos como algo habitual: pierde la confirmación, no está segura de
que funcionara, cambia una respuesta. En un formulario de solicitud real, **49 envíos procedían de
41 personas**. Solo con creación se habrían producido ocho contactos duplicados en un formulario
así de pequeño, cada uno con su propio email posterior, y la factura de la deduplicación llega más
tarde y con intereses.
### Suponer que el solicitante es un lead
Formulario público, persona desconocida: por tanto, un lead, seguro. No necesariamente. Alguien
que se une a un programa está entrando en una relación, no en un pipeline de ventas: no tiene
oportunidad, ni valor, ni fecha de cierre, y meterlo en un pipeline falsea todas las métricas del
pipeline. Vincule el formulario a la entidad que corresponde a lo que la persona realmente es. La
cuestión de dónde ubicarlo es el [Blueprint
003](https://blueprints.coevera.com/es/blueprints/where-should-this-data-live/).
## 03 · Modelo de datos
Las tres entidades implicadas (la definición del formulario, la respuesta y la unión de relación)
se tratan en el [Blueprint
012](https://blueprints.coevera.com/es/blueprints/customer-survey-answers-onto-the-record/). Lo
que es específico aquí es la frontera entre la web y el CRM.
**Fuentes.** Centro de ayuda de Coevera, [Working with online
forms](https://help.coevera.com/en/articles/8039971-working-with-online-forms) para el formulario
en sí y para la incrustación por iframe usada aquí, que describe como la opción más sencilla pero
con limitaciones; y [Working with online forms in
JavaScript](https://help.coevera.com/en/articles/8287702-working-with-online-forms-in-javascript-developers-tutorial)
para la otra vía, un formulario incrustado por script que forma parte de la página.
### El acoplamiento es una única cadena opaca
Una definición de formulario expone `linkId`, y el formulario público se sirve desde una URL con
la forma:
```
https://forms.{vendor-host}/{link-id}/viewform
```
La web guarda esa URL y un título legible, y nada más. En una implementación real, el propio
modelo de contenido de la página contiene exactamente dos claves para el formulario (la URL y el
título), y el botón lo abre en un marco modal en el momento del clic. El título no es decorativo:
se convierte en el nombre accesible del marco, que es lo único que un lector de pantalla tiene
para anunciar antes de que se cargue el contenido del marco.
> **Por qué esto es lo esencial.** Como la web no contiene nombres de campos, añadir, eliminar o
> reordenar una pregunta es un cambio en el CRM sin publicar la web. Y como no contiene ninguna
> credencial, nadie que lea el código fuente de la página puede convertirla en una vía de
> escritura contra su CRM.
### Lo que cuesta realmente incrustarlo
La respuesta del formulario alojado no lleva `X-Frame-Options` ni ninguna restricción
`frame-ancestors`, que es precisamente por lo que se puede incrustar en cualquier sitio.
Incrustado como iframe, como aquí, se derivan tres consecuencias, y las tres suelen descubrirse
tarde:
- **No es rastreable.** Dentro del iframe las preguntas se renderizan por script, así que los
motores de búsqueda y los modelos ven el armazón. Cualquier contenido que deba indexarse tiene
que estar en la página alrededor del marco, no dentro de él.
- **Sin JavaScript no hay formulario.** No un formulario degradado: nada.
- **La página contenedora no puede ver dentro del marco.** Con el formulario en un iframe, su
analítica y sus herramientas de consentimiento observan el clic que lo abrió y nada después, así
que el abandono a nivel de campo es invisible desde fuera.
Y como nada restringe quién puede enmarcarlo, el mismo formulario puede incrustarse en un sitio
que no es suyo. El link id es el único secreto, y está en el código fuente de su página.
### Los campos de formulario se comparten entre formularios
Las definiciones de campos de formulario viven en un repositorio común a todo el espacio y no
dentro de un formulario. Cuatro identificadores de campo de este formulario de solicitud (nombre,
apellidos, email, empresa) son idénticos a los de una encuesta a clientes no relacionada del mismo
espacio. Así que «añadir una pregunta de email» reutiliza una definición existente en lugar de
crear una nueva. No se probó si editar una definición compartida se propaga a todos los
formularios que la usan; compruébelo antes de renombrar una.
### Lo que el registro necesita y el visitante no puede dar
Un registro creado sigue teniendo que cumplir los requisitos ordinarios de la plataforma, y un
envío anónimo no cumple ninguno:
| Requisito | De dónde procede |
|---|---|
| Propietario | Un id fijo en la plantilla de creación. No hay nadie de quien deducirlo |
| Unidad de ventas | También fija. Se espera que un registro con propietario y sin unidad se rechace; ningún envío lo probó |
| Subtipo | Un id de tipo fijo, para que los solicitantes se distingan a nivel de registro de todos los demás en la misma entidad: el patrón de discriminador del [Blueprint 001](https://blueprints.coevera.com/es/blueprints/one-entity-five-request-types/) |
| Procedencia | La sella la plantilla; véase §4 |
## 04 · Configuración a nivel de campo
### El conjunto de preguntas, y lo que debería significar «obligatorio»
El formulario real hace once preguntas, nueve de ellas obligatorias:
| Pregunta | Tipo de campo del formulario | Obligatoria |
|---|---|---|
| Nombre, Apellidos | entrada de una línea | sí |
| E-mail | email | sí, y es la clave de autolink |
| Teléfono | entrada de una línea | sí |
| Nombre de la empresa | entrada de una línea | **no** |
| Calle | **área de texto** | sí |
| Ciudad, Código postal, País | entrada de una línea | sí |
| Estado/provincia | entrada de una línea | no |
| Privacidad y protección de datos | casilla de verificación | sí |
De esa tabla merece la pena copiar dos cosas. Primero, **el tipo de campo del formulario sigue al
tipo de campo del CRM, no a la pregunta**: la pregunta de la calle es un área de texto porque el
campo de dirección del contacto subyacente es multilínea, y ninguna configuración del formulario
lo cambia. Segundo, el conjunto obligatorio no es la lista de deseos de marketing: la dirección
postal completa es obligatoria porque el programa paga a las personas y no puede avanzar sin ella,
mientras que el nombre de la empresa (el campo en el que insistiría un responsable de marketing)
es opcional. **Exija lo que el siguiente paso realmente no puede ejecutar sin ello**, y nada más.
Observe también que todos los campos tienen el prerrelleno desactivado. No hay ningún registro del
que prerrellenar; la combinación de prerrelleno y autolink que identifica a un cliente conocido en
el [Blueprint
012](https://blueprints.coevera.com/es/blueprints/customer-survey-answers-onto-the-record/) no se
aplica cuando quien responde es un desconocido.
### Los tres ajustes que lo convierten en un upsert
| Ajuste | Valor | Efecto |
|---|---|---|
| `createRecordEnabled` | `true` | Un envío sin coincidencia se convierte en un registro nuevo |
| `updateRecordEnabled` | `true` | Un envío con coincidencia actualiza el existente |
| `autolinkEnabled` | `true` | Decide cuál de los dos ocurre |
| `autolinkFormFieldId` / `autolinkRecordFieldId` | la pregunta de email / el campo de email del contacto | La coincidencia. Son dos identificadores separados en dos espacios de ids distintos: emparejarlos es toda la configuración |
| `linkRecordEnabled` | `false` | No hay nada que vincular; la identidad la establece la respuesta, no un envío |
| `limitToSingleResponse` / `checkForExistingResponse` | `false` | **Correcto aquí.** Los envíos repetidos son el mecanismo, no el problema |
### La plantilla de creación
Con `createRecordEnabled`, el formulario lleva una plantilla de registro. Es una **carga útil
completa del registro, no un parche**: enumera los campos estándar, incluidas las cinco ranuras de
teléfono y las cinco ranuras de email, la mayoría vacías:
```
{
"contactTypeId": "{sub-type-id}",
"ownerId": "{nominated-owner-id}",
"unitId": "{nominated-unit-id}",
"firstName": "",
"lastName": "",
"email1": "",
"phone1": "",
"address": "",
"city": "…", "zipCode": "…", "stateProvince": "…", "country": "…",
"email2": "", "email3": "", "phone2": "", "phone3": "",
"middleName": "", "title": "", "position": "",
"accountRelations": [], "tags": [], "staticProfiles": [],
"shareMode": "Standard",
"isUnsubscribed": false,
"comments": "Created via {a hand-typed page path}",
"customFields": {
"cfRegistrationDate": "",
"cfSource": "{the page URL}"
}
}
```
Las cinco decisiones dentro de esa carga útil:
- **El subtipo se fija en la creación.** Esto es lo que convierte a «todos los que se inscribieron
a través de la web» en un conjunto filtrable y no en una suposición.
- **El propietario y la unidad se designan, no se deducen.** Ambos son obligatorios y ninguno
puede venir del visitante. Elija un marcador de posición deliberado en lugar de la cuenta de una
persona real, o el marcador de posición se convertirá por accidente en la carga de trabajo de
alguien.
- **La procedencia se sella dos veces**: una en el texto del comentario y otra en un campo de
origen específico. Prefiera el campo: es filtrable, sirve para informes y no se deteriora. Lo
que nos lleva al siguiente punto.
- **La procedencia escrita a mano diverge.** En la plantilla real, la cadena del comentario y el
campo de origen no coinciden en la ruta de la página, porque uno de ellos se escribió y nunca se
revisó. Nada valida una cadena de texto libre frente a la realidad. Mantenga una única fuente de
verdad y haga que sea un campo.
- **La fecha de registro procede de `CurrentDate`**, no de un proceso que se ejecuta más tarde.
> **La casilla de consentimiento no está en el registro.** La casilla de privacidad es obligatoria
> para enviar, y no aparece en ninguna parte de la plantilla de creación. Así que el
> consentimiento existe en el registro de la respuesta y dentro del PDF de la respuesta, y **no se
> puede consultar en el contacto**. Si alguna vez necesita filtrar, informar o demostrar el
> consentimiento de forma masiva, mapéelo explícitamente a un campo propio. Nada le avisa de que
> una pregunta obligatoria no fue a ninguna parte.
### La notificación, y el ajuste que la gente configura al revés
Active `notificationEnabled` y diríjala al **propietario del formulario**, no al propietario
principal del registro. En un formulario de captación, el propietario del registro creado es el
marcador de posición designado en la plantilla, así que notificar al propietario del registro
envía un correo a un marcador de posición. Es lo contrario de la respuesta correcta en una
encuesta enviada a un cliente existente, donde el propietario del registro es la persona que
necesita saberlo.
### El resto, en breve
- **reCAPTCHA es un indicador por formulario.** Está desactivado en este formulario y activado en
el formulario de contacto general del mismo espacio. Un formulario público sin él acumulará
basura, y basura en un formulario de upsert son registros basura.
- **`attachResponseAsPdf`** archiva el envío en el registro. En cualquier cosa que se parezca a
una solicitud o a un acuerdo, esto es lo que hace defendible el registro un año después.
- **La página de confirmación es una promesa.** Configurarla para que diga «revise su email para
ver las instrucciones» crea una obligación que el §5 tiene que cumplir.
## 05 · Automatización y lógica
### El manejador del envío
Un proceso, vinculado a este formulario concreto por su id, que se dispara con el envío. Su
entidad disparadora es la **respuesta** y su tipo de registro es el contacto al que se resolvió la
respuesta, así que el proceso puede leer las respuestas y actuar sobre la persona en la misma
ejecución. En la implementación real es deliberadamente pequeño (un filtro, un email) y existe
para cumplir la frase de la página de confirmación.
**Latencia observada:** el proceso se ejecutó por última vez unos **ocho segundos** después de la
última respuesta registrada del formulario. Es una observación, no un benchmark, pero resuelve la
cuestión de diseño: es un traspaso en vivo, no un lote, así que el email de acuse de recibo puede
formar parte de la experiencia del envío.
### Recuperar la métrica con un segundo formulario, enviado
El patrón que merece la pena copiar es lo que ocurre después. El formulario de solicitud está
incrustado, así que nunca puede informar de una tasa. El formulario de *acuerdo* que viene a
continuación se **envía**, y un formulario enviado informa de todo. El embudo real, de principio a
fin:
| Etapa | Medido | Lo que informa la plataforma |
|---|---|---|
| Formulario de solicitud incrustado | 49 envíos → **41 personas distintas**, 0 sin coincidencia | Tasa de respuesta: **en blanco**. Recuento de envíos cero |
| Formulario de acuerdo enviado | 144 envíos a esas 41 personas → **35 firmados** | Tasa de respuesta: **85,4 %**, más una lista de sin respuesta |
De esa tabla se desprenden dos lecturas. La obvia: **ponga la etapa medible donde está la
decisión**. La más sutil: `sentCount ÷ sentUniqueCount` es 144 ÷ 41 ≈ 3,5, así que la proporción
entre los dos contadores de envíos le dice cuántas veces hizo seguimiento a cada persona, un
número que nada más en la plataforma muestra.
### Hacer seguimiento a quienes no terminaron
Un formulario incrustado no tiene lista de sin respuesta, porque no tiene lista de envíos. Así que
el seguimiento tiene que reconstruirse al otro lado: un **proceso programado sobre los registros
creados**, filtrado a los que llegaron al estado de solicitud y nunca llegaron al de completado,
que envía un recordatorio.
Esta es la lección estructural de todo el blueprint. Cada medición que un formulario incrustado no
puede darle tiene que reconstruirse como informes sobre los registros que ha creado, lo cual solo
es posible porque el §4 insistió en un subtipo, un campo de procedencia y una fecha de registro.
Esos tres campos son por los que filtra el proceso de seguimiento. Si los omite en la creación, el
seguimiento no se puede construir en absoluto.
### Mantener legible la familia
Un embudo como este llega rápidamente a varios procesos: acusar recibo de la solicitud, reaccionar
a la firma, hacer seguimiento a quienes no firmaron, puntuar al solicitante, lanzar la campaña.
Son procesos separados porque un proceso lleva un filtro cuyas ramas se rigen por la primera
coincidencia, y estas condiciones pueden cumplirse todas a la vez; la restricción y la disciplina
de nombres están en el [Blueprint
011](https://blueprints.coevera.com/es/blueprints/keeping-hundreds-of-automations-maintainable/).
Vincule cada uno a los ids de formulario concretos a los que sirve; un disparador acepta una
**lista** de formularios, así que una familia de formularios casi idénticos puede compartir un
único proceso en lugar de multiplicarlo.
## 06 · Límites y compromisos
> **La plataforma no puede medir un formulario incrustado.** La tasa de respuesta es respuestas ÷
> destinatarios únicos, y un formulario incrustado no tiene destinatarios, así que la tasa queda
> en blanco y la lista de enviados sin respuesta está vacía por muchas personas que envíen el
> formulario. Es aritmética, no un error, y ningún ajuste lo cambia.
- **Una pregunta obligatoria puede no ir a ninguna parte.** Verificado en el formulario real: la
casilla de privacidad es obligatoria para enviar y no figura en la plantilla de creación, así
que el consentimiento se registra en la respuesta y no en el contacto. El mismo silencio se
aplica a cualquier pregunta que nadie haya mapeado: la respuesta se almacena, y no está en el
registro.
- **Un upsert por email es una vía de escritura basada en un identificador adivinable.**
Cualquiera que envíe una dirección conocida actualiza el registro de esa persona. En un
formulario de primer contacto, la exposición suele ser aceptable, porque los campos editables
son los que esa persona controla de todos modos, pero es una decisión, no un valor
predeterminado, y es el mismo mecanismo señalado como riesgo para las encuestas en el [Blueprint
012](https://blueprints.coevera.com/es/blueprints/customer-survey-answers-onto-the-record/).
Cuando el formulario actualice algo comercialmente relevante, haga coincidir con un valor que
solo la persona prevista pueda tener.
- **El mismo ajuste es correcto en un diseño e incorrecto en otro.** Dejar sin restricción las
respuestas repetidas es lo que hace funcionar el upsert aquí; en una encuesta enviada es lo que
lleva la tasa de respuesta por encima del 100 %. No hay un valor predeterminado seguro: decida
para cada formulario cuál de los dos está construyendo.
- **El número de campos obligatorios es un coste de conversión que usted no puede ver.** Nueve
campos obligatorios, incluida una dirección postal completa, es mucho pedir a un desconocido, y
el abandono ocurre dentro de un marco que la página contenedora no puede observar. Verá los
envíos que se completaron y nunca los que no, así que este compromiso tiene que razonarse en
lugar de medirse.
- **En un iframe, el formulario es invisible para los rastreadores y para los visitantes sin
JavaScript**, y su contenido no puede aportar nada al peso de búsqueda o de citación de la
página.
- **Nada restringe quién puede enmarcarlo.** Sin frame-ancestors, sin X-Frame-Options: la
propiedad que hace trivial la incrustación también significa que el formulario funciona en
cualquier sitio que conozca el link id, y el link id está en el código fuente de su página.
- **La procedencia escrita como texto libre diverge**, en silencio y para siempre. Dos mecanismos
de procedencia en un mismo formulario real ya no coinciden.
- **La propiedad se aplaza, no se resuelve.** El propietario designado satisface a la plataforma y
no asigna el trabajo a nadie. Un proceso de enrutamiento o una vista compartida es un trabajo
aparte, y olvidarlo es como un formulario de captación acaba alimentando una cola que ningún
humano abre.
- **Las definiciones de campos se comparten en todo el espacio.** Aparecen identificadores de
campo idénticos en formularios no relacionados del mismo espacio. Práctico para reutilizar; no
se probó cómo se propaga una edición, así que trate el cambio de nombre de una pregunta
compartida como un cambio en todos los formularios que la usan mientras no se demuestre lo
contrario.
### El compromiso que conviene exponer claramente
Alojar el formulario en el CRM le da lo que más importa y más cuesta incorporar a posteriori: la
web deja de saber nada de su modelo de datos. Las preguntas cambian sin publicación, ninguna
credencial sale del CRM, y el registro llega con tipo, propietario y sello. A lo que renuncia es a
todo lo que depende de ver el formulario como parte de su página: integración visual más allá del
propio estilo del formulario, analítica del embudo por campo, contenido indexable y un formulario
que funcione sin JavaScript. Para un formulario de inscripción detrás de un botón, es un buen
intercambio. Para un formulario que *es* la landing page, no lo es, y la respuesta honesta en ese
caso es una página construida a mano que envíe a la API y asuma el coste de mantenimiento que
describe el §2.
## 07 · Verificación
Leído el 2026-09-10 en un espacio de producción real y en la página pública real que incrusta el
formulario: un formulario de solicitud a un programa de partners en servicio desde abril de 2026.
- **El acoplamiento se verificó desde ambos extremos.** El link id almacenado en la definición del
formulario es idéntico byte a byte al id de la URL que guarda el modelo de contenido de la
página pública, que contiene exactamente dos claves para el formulario: esa URL y un título
accesible.
- **Se consultó el endpoint público.** Devuelve HTTP 200 con un armazón HTML de ~1,7 KB que
contiene un elemento personalizado y tres scripts de módulo de una CDN estática, y ninguna
cabecera `X-Frame-Options` ni `frame-ancestors`, que es la base de todas las afirmaciones sobre
la incrustación del §3.
- **El upsert se confirmó con sus propios contadores:** 49 respuestas, 41 registros en la
categoría de respondidos, 0 encuestados desconocidos. Por tanto, ocho envíos coincidieron con un
registro existente en lugar de crear uno, sin que nada quedara sin coincidencia.
- **Los ajustes y la plantilla de creación se leyeron literalmente**: los tres indicadores del
upsert, el par de autolink, el subtipo, los ids fijos de propietario y unidad, ambos sellos de
procedencia, y la ausencia de cualquier campo de consentimiento. La enumeración en la plantilla
de las cinco ranuras de teléfono y las cinco de email es lo que establece que es una carga útil
completa y no un parche.
- **El conjunto de campos se leyó entero:** once preguntas, nueve obligatorias, prerrelleno
desactivado en todas ellas, la pregunta de la calle un área de texto donde sus hermanas son
entradas de una línea.
- **Se rastreó la automatización:** un proceso vinculado solo a este id de formulario, con la
respuesta como entidad disparadora y el contacto como tipo de registro, dos nodos. La marca de
tiempo de su última ejecución es unos ocho segundos posterior a la marca de tiempo de la última
respuesta del formulario.
- **Las cifras del embudo se leyeron de los propios contadores de los dos formularios**, y la
cifra del 85,4 % se reproduce exactamente como 35 ÷ 41: la misma aritmética de respuestas sobre
destinatarios únicos verificada en todo un conjunto de formularios en el [Blueprint
012](https://blueprints.coevera.com/es/blueprints/customer-survey-answers-onto-the-record/).
**No observado, y se indica como tal:**
- Un envío hecho a propósito. Cada hallazgo se ha leído de la configuración almacenada, los
resultados almacenados y el endpoint público, no de datos de prueba enviados a través de un
formulario real.
- Si editar una definición compartida de campo de formulario se propaga a los demás formularios
que la usan.
- Si un valor vacío en la plantilla de creación escribe un vacío o se omite.
- El comportamiento de reCAPTCHA en sí; solo que es un indicador por formulario, desactivado en
este formulario y activado en otro del mismo espacio.
### Qué indicaría una regresión
- **Que los encuestados desconocidos suban por encima de cero** en un formulario de upsert
significa que el par de autolink se ha roto, y como la creación sigue funcionando, se presenta
como un formulario sano que produce registros que nadie encuentra.
- **Que el número de registros crezca al mismo ritmo que el número de respuestas.** En un
formulario con envíos repetidos, un registro por respuesta significa que la coincidencia ha
dejado de producirse y que usted está acumulando duplicados.
- **Que sigan llegando respuestas mientras el acuse de recibo se detiene.** La página de
confirmación seguirá prometiendo un email de todos modos; la promesa y el proceso se configuran
en lugares distintos y nada los une.
- **Que el número de registros del propietario designado crezca sin que se ejecute el proceso de
seguimiento.** Esa es la firma de un formulario de captación que alimenta una cola que nadie
trabaja.
## Blueprints relacionados
- [Blueprint 012 — ¿Cómo lanza una encuesta a clientes desde su CRM y recupera las respuestas en
el
registro?](https://blueprints.coevera.com/es/blueprints/customer-survey-answers-onto-the-record/)
— el modelo de datos de los formularios en línea, el prerrelleno con autolink para clientes
conocidos y la aritmética de la tasa de respuesta.
- [Blueprint 011 — ¿Cómo mantiene cientos de automatizaciones del CRM de forma
sostenible?](https://blueprints.coevera.com/es/blueprints/keeping-hundreds-of-automations-maintainable/)
— por qué un embudo de captación se convierte en varios procesos, y cómo nombrarlos.
- [Blueprint 003 — ¿Cómo modela algo para lo que su CRM no tiene un
objeto?](https://blueprints.coevera.com/es/blueprints/where-should-this-data-live/) — decidir en
qué entidad debe convertirse un envío público.
- [Blueprint 001 — ¿Cómo gestiona cinco tipos distintos de solicitudes de clientes en un único
servicio de
asistencia?](https://blueprints.coevera.com/es/blueprints/one-entity-five-request-types/) — el
discriminador de subtipo que fija la plantilla de creación.
- [Blueprint 005 — ¿Cómo migra contactos desde otro sistema sin perder datos sin darse
cuenta?](https://blueprints.coevera.com/es/blueprints/contact-migration-without-data-loss/) —
por qué el email es una clave de deduplicación frágil a gran escala.
## Preguntas frecuentes
### ¿Cómo añade a su web un formulario de contacto que escriba directamente en su CRM?
El CRM aloja el formulario y la web lo incrusta. Cada definición de formulario lleva un link id, y el formulario público vive en una URL construida a partir de ese id; la página solo contiene esa URL y un título accesible, de modo que en la web no hay marcado del formulario, ni lista de campos, ni clave de API. Activar juntos crear registro, actualizar registro y autolink convierte un envío en un upsert: el email enviado se compara con el campo de email del contacto, así que un solicitante que vuelve actualiza su propio registro en lugar de crear un segundo.
### ¿Cómo evita que un formulario público cree registros duplicados?
Active autolink junto con crear registro y actualizar registro. Autolink designa un campo del formulario y un campo del registro; cuando un envío coincide con un registro existente, actualiza ese registro, y solo un envío sin coincidencia crea uno nuevo. En un formulario de solicitud real, esto redujo 49 envíos a 41 personas distintas, sin ninguna respuesta sin coincidencia.
### ¿Por qué un formulario incrustado no muestra tasa de respuesta?
Porque la tasa de respuesta integrada es el número de respuestas dividido entre los destinatarios únicos, y un formulario incrustado no tiene destinatarios. Su recuento de envíos es cero, así que el divisor es cero y la tasa queda en blanco por muchas personas que envíen el formulario. Lo mismo ocurre con la lista de enviados sin respuesta, de modo que un formulario incrustado tampoco tiene una lista nativa de seguimiento: ambas cosas deben reconstruirse como informes sobre los registros que ha creado.
### ¿Una casilla de consentimiento obligatoria en un formulario se convierte en un campo del registro?
No, a menos que usted la mapee. Una casilla de privacidad puede ser obligatoria para enviar y aun así no figurar en la plantilla de creación del registro; en ese caso, el consentimiento solo sobrevive en el registro de la respuesta y en su PDF adjunto, y no se puede consultar en el contacto. Cualquier consentimiento que necesite filtrar o demostrar de forma masiva debe mapearse explícitamente a un campo propio.
### ¿Quién es el propietario de un registro creado por un visitante anónimo de la web?
Quien usted designe en la plantilla de creación. Todo registro requiere un propietario y una unidad de ventas, y un envío anónimo no aporta ninguno de los dos, así que la plantilla lleva ids fijos. La asignación a una persona real es, por tanto, una cuestión aparte: un proceso de enrutamiento o una vista compartida sobre los registros del propietario designado, no algo que el formulario pueda decidir.
---
Publicado por Coevera. Abstraído al patrón reutilizable: sin nombres de clientes, sin datos
de clientes, sin datos personales.