Configura los campos obligatorios de HubSpot en el punto en que alguien pueda aportar con veracidad la información necesaria para la siguiente decisión. Para un cambio manual de etapa del negocio, utiliza el ajuste de la etapa correspondiente y comprueba valores ausentes y completos antes del despliegue. La entrada automatizada requiere otra comprobación, porque la regla configurada y la vía de software utilizada para enviar los datos pueden cambiar lo que sucede.
Un negocio está listo para avanzar, pero la pantalla solicita datos que todavía nadie conoce. En otro punto, un registro llega al siguiente compañero con un campo vacío. Empezamos por anotar la decisión que necesita esa información. Esta guía trata los requisitos de las etapas del negocio; un formulario web o un panel de creación de registros tiene sus propios ajustes.
¿Qué regla de campos obligatorios de HubSpot vas a cambiar?
Determina cuándo se necesita la información antes de elegir un ajuste. La guía de HubSpot sobre pipelines distingue entre mostrar un campo en una etapa y exigir su valor. Su guía sobre formularios de creación describe los requisitos al crear manualmente un registro. Estos controles actúan en momentos distintos: la entrada inicial y una entrega posterior pueden necesitar información diferente.

Una propiedad es un campo de un registro. Un pipeline es la secuencia de etapas por las que avanza un negocio. Utiliza las siguientes distinciones al preguntar a tu administrador qué está configurado.
| Control | Pregunta que responde |
|---|---|
| Requisito del formulario de creación | ¿Qué debe introducirse cuando alguien crea manualmente el registro? |
| Propiedad condicional de etapa | ¿Qué debe mostrarse o exigirse cuando alguien crea manualmente un registro en esta etapa o lo mueve a ella? |
| Lógica condicional de propiedades | ¿Qué otros campos deben solicitarse cuando una propiedad de control cumple una condición? |
| Opción “Required” del formulario web | ¿Qué debe completar un visitante para enviar este formulario? |
| Validación de valores | ¿Cumple el valor introducido una regla admitida de formato o intervalo? |
HubSpot documenta estas funciones como controles separados, cada uno con su propia disponibilidad y alcance. Que un campo aparezca en pantalla no demuestra que impida guardar. Un campo que no esté vacío también debe contener una respuesta útil.
Decide qué necesita saber el siguiente compañero
Escribe la decisión prevista con palabras sencillas y después indica la información necesaria para tomarla. Para cada campo obligatorio propuesto, anota quién utiliza la respuesta, cuándo puede conocerse y qué debe explicar un valor útil. Si nadie puede explicar su uso, mantén el requisito en revisión.
Por ejemplo, un compañero puede necesitar una explicación clara de lo que ha solicitado el posible cliente antes de preparar una propuesta. Acuerda qué debe contener esa explicación. Pedir antes una respuesta basada en una suposición dejaría la decisión sin resolver aunque el campo contuviera texto.
Mantén una forma explícita de gestionar la información que todavía se desconoce. Pide a la persona responsable que revise la etapa o el momento en que se aplica el requisito. Conserva los datos existentes y comprueba las dependencias antes de modificar una regla; eliminar campos o añadir valores ficticios queda fuera de este procedimiento.
Si varios registros contradictorios impiden saber de quién es la información que estás cambiando, resuelve primero la cuestión de identidad. Nuestra guía específica para revisar contactos duplicados en HubSpot explica por qué una combinación necesita sus propias comprobaciones.
Configura el campo para la etapa prevista del negocio
Sigue el procedimiento de etapas documentado por HubSpot con un administrador existente y autorizado. La guía de pipelines exige el permiso “Edit property settings” y una propiedad dependiente existente que se pueda editar. Comprueba la suscripción y la disponibilidad del objeto en la cuenta real antes de continuar; si falta un control, consulta al administrador en lugar de comprar una mejora basándote en una suposición.
Antes de cambiar nada, registra la regla anterior y acuerda cómo restaurarla. Prepara registros de prueba aprobados en un entorno donde las comprobaciones no puedan contactar con clientes, activar campañas o facturación ni modificar informes en producción. Si no dispones de ese aislamiento, pide al administrador que lo prepare antes de hacer las pruebas.
- Abre “Settings” y, después, “Data Management” y “Objects”. Selecciona el objeto correspondiente y su pestaña “Pipelines”.
- Selecciona el pipeline previsto. En la fila de la etapa de destino, abre “Add rule”, dentro de “Conditional logic rules”.
- Confirma la condición de la etapa y añade la propiedad dependiente. Selecciona “Required” cuando la ausencia del valor deba impedir la acción manual incluida.
- Selecciona “Save logic” y registra exactamente la etapa y la propiedad que cubre la regla.
Según la misma guía, las propiedades de solo lectura, incluidos los valores calculados y de puntuación, no pueden utilizarse como propiedades de etapa. Si el campo no está disponible, comprueba su definición antes de crear otro con la misma finalidad.
Comprueba valores ausentes y completos antes del despliegue
Prueba la condición acordada con un registro sintético aprobado y anota el resultado esperado antes de realizar la acción. Empieza con el campo seleccionado vacío y después introduce un valor de prueba significativo. Tras volver a abrir el registro, revisa la etapa y el campo guardados. El resultado solo se aplica a la condición, persona o sistema y vía que hayas comprobado realmente.

- Intenta realizar el cambio manual de etapa incluido sin el valor dependiente. Anota si el aviso correspondiente impide guardar; un resultado inesperado seguirá siendo una cuestión pendiente.
- Introduce un valor de prueba claramente ficticio que siga correspondiendo al significado acordado. Repite la acción y revisa lo que se ha guardado.
- Comprueba por separado una etapa que no esté incluida en la condición configurada para detectar un requisito inesperadamente amplio.
- Conserva juntos el estado inicial, el resultado esperado, el resultado observado y la persona responsable de cualquier discrepancia.
Utiliza el mismo registro con cuidado para evitar que un valor guardado con anterioridad invalide una prueba posterior de ausencia de valor. Pide al administrador que prepare el estado inicial previsto. Completar una interacción en pantalla no basta para demostrar el resultado almacenado.
Comprueba las vías que escriben en tus registros
El éxito manual no demuestra cómo gestiona el requisito un workflow, una importación, un formulario web o un conector. Un workflow es un proceso automatizado dentro de HubSpot; una API es la interfaz de software que puede utilizar un conector para escribir registros. La guía de HubSpot sobre propiedades condicionales excluye las ediciones mediante workflows de su cobertura manual documentada.
Su registro de cambios para desarrolladores describe la aplicación de las propiedades condicionales obligatorias configuradas y de los requisitos de creación de registros en la versión 2026-09 de la API; los requisitos de creación se aplican a las solicitudes POST. La vía y la versión que utiliza realmente un conector son relevantes.
Pide a la persona que mantiene cada vía utilizada que identifique la regla y ejecute comprobaciones aprobadas con entradas ausentes y completas. No es necesario añadir una importación o integración solo para probarla. Conserva un resultado separado para cada vía existente, incluido el mensaje devuelto y, cuando puedan revisarse, la etapa y el valor almacenados.
El registro de cambios de la API desaconseja volver a intentar la misma solicitud rechazada sin modificarla. Si se rechaza una escritura, conserva la consulta mediante el proceso aprobado y asigna la corrección a un responsable visible. Investiga la información o la correspondencia que falta antes de repetir la prueba; no debilites la regla solo para conseguir que se acepte la solicitud.
En nuestras comprobaciones de configuración e integración de CRM, conectamos cada decisión sobre un campo con las vías que escriben en él. Si una etapa también alimenta la medición de publicidad de pago, acuerda qué significa ese estado antes de utilizarlo allí. Rellenar un campo no demuestra que exista una venta ni un resultado publicitario válido.
Qué debes revisar después del cambio
Revisa el requisito de acuerdo con la decisión que debía respaldar. Compara el mismo tipo de registros y vías antes y después del cambio. Mantén visibles las vías no comprobadas y repite las comprobaciones afectadas tras un cambio pertinente en una regla o integración. Conserva los límites originales de una prueba manual superada.
- ¿Son útiles los valores para la decisión del siguiente compañero o se están introduciendo valores de relleno?
- ¿Puede la persona responsable ver y corregir las escrituras incompletas o rechazadas?
- ¿Sigue visible un desconocimiento expresado con sinceridad y acompañado de una siguiente acción acordada?
- ¿Qué etapas, actores o vías de escritura siguen sin tener un resultado registrado?
Estas observaciones sirven para tomar la siguiente decisión de configuración. No demuestran una mejora de las ventas ni prueban que todos los valores introducidos sean ciertos.
Dónde intervenimos
Empezamos por la finalidad del campo, la etapa en que se conoce la información y la persona que la necesita. Relacionamos esa decisión con el ajuste existente y una comprobación para cada vía en uso. Anota la etapa problemática, la información que falta y todas las vías que escriben en el registro. No necesitas exportaciones de clientes ni credenciales de la cuenta para definir esta cuestión.