Campos dependientes: cuando un campo aparece o se vuelve obligatorio según el valor de otro campo; campos ocultos: cuando los campos innecesarios se retiran del formulario para no estorbar al gestor. Un constructor de dependencias completo del tipo «mostrar el campo B con el valor del campo A» no existe en Bitrix24 (Alaio), pero el mismo efecto se consigue combinando ajustes estándar y robots: configuración de la ficha, obligatoriedad por etapas, comprobaciones en el proceso de negocio y autolimpieza de los valores irrelevantes. Veamos la técnica paso a paso.
¿Para qué sirven los campos dependientes y ocultos?
La ficha de una negociación se llena de campos: para personas jurídicas hacen falta el NIF y el domicilio fiscal, para personas físicas, los datos del documento de identidad, para la entrega, la dirección y la franja horaria. Si se muestra todo a todos, el gestor ve un muro de decenas de campos, los rellena salteados y se salta lo importante. Los campos dependientes y ocultos resuelven este problema: el formulario muestra solo lo que corresponde al cliente actual y a la etapa de trabajo. El beneficio directo es la velocidad de relleno y la limpieza de los datos: cuantos menos campos irrelevantes en pantalla, menos valores de «solo para guardar» llegan al CRM, y más precisos son los filtros, informes y documentos construidos sobre esos campos.
¿Qué permite la configuración estándar de la ficha?
La ficha del CRM se puede configurar sin código: ocultar campos, cambiar el orden, agrupar campos en secciones y guardar la vista común para todos los empleados. Es una ocultación estática: el campo se ve o no, y la visibilidad no depende del valor de otros campos. El segundo mecanismo estándar es la obligatoriedad por etapas: un campo se vuelve obligatorio cuando la negociación pasa a una etapa determinada (más sobre la obligatoriedad y los tipos de campos, en el artículo sobre los campos en Bitrix24). Una dependencia dinámica del tipo «se eligió "Persona jurídica" y apareció el bloque de datos de registro» la interfaz estándar no la ofrece, por eso la dependencia se emula combinando secciones de la ficha, obligatoriedad por etapas y robots de comprobación: de ello tratan las dos secciones siguientes.
¿Cómo emular la dependencia mediante etapas y obligatoriedad?
La idea: en lugar de «mostrar el campo con un valor», «exigir el campo en la etapa donde se vuelve necesario». Ejemplo con la entrega: mientras la negociación está en «Negociaciones», los campos de entrega no son obligatorios y están en una sección plegada al final de la ficha; al pasar a la etapa «Entrega», la dirección y la franja horaria se vuelven obligatorias, y la ficha exige por sí misma rellenarlas al cambiar de etapa. Una sección plegada con campos poco frecuentes funciona visualmente como una ocultación, y la obligatoriedad por etapa, como una dependencia de la etapa. Limitación de la técnica: la comprobación solo se activa en las transiciones manuales; los cambios por API, por importación o por robots la eluden. Ese agujero lo cierra la comprobación de combinaciones de campos en el proceso de negocio.
¿Cómo comprobar una combinación de campos con un robot?
La dependencia «si A, entonces B es obligatorio» son dos condiciones a la vez: «Tipo de cliente = Persona jurídica» Y «NIF vacío». El bloque estándar «Condición» del diseñador de procesos expresa esto con una cadena de bloques anidados que rápidamente se vuelve ilegible. El robot «Condición compuesta (AND / OR / NOT)» comprueba hasta cuatro condiciones con lógica AND u OR en una sola acción, y en modo JSON acepta un árbol de condiciones de anidamiento arbitrario, y devuelve un único indicador Y/N. Entre los operadores: igual, distinto, mayor, menor, contiene, vacío, no vacío; las cadenas, por defecto, se comparan sin distinguir mayúsculas y minúsculas. Si N, el proceso devuelve la negociación a la etapa anterior o pone al gestor una tarea con la lista de los campos sin rellenar.
¿Cómo insertar y limpiar valores dependientes?
Dos robots cubren la otra cara de la dependencia. «Selección ternaria (si-entonces-si no)» compara dos valores y devuelve uno de los dos resultados indicados más el indicador de cumplimiento de la condición Y/N: por ejemplo, según el campo «Tipo de cliente» inserta en el correo la fórmula de tratamiento adecuada, sin una cadena de condiciones en el diseñador. Y «Limpiar campo» establece un valor vacío en cualquier campo de una negociación, contacto, empresa o prospecto: si el gestor cambió el tipo de cliente de «Persona jurídica» a «Persona física», el robot limpia el NIF y el domicilio fiscal para que los datos de la variante anterior no acaben en documentos e informes. Cómo colgar robots en las etapas, en el artículo sobre la configuración de robots.
¿Cómo agrupar los campos en secciones de la ficha?
Los campos de la ficha de una negociación, prospecto, contacto o empresa se agrupan en secciones sin nada adicional. En la ficha, pulsa «Crear sección», ponle nombre («Entrega», «Pago», «Documentos») y arrastra a ella los campos que necesites tirando de su borde izquierdo. Una sección se puede plegar, renombrar o eliminar, y los campos de dentro se pueden reordenar. Mientras reorganizas la ficha, los cambios solo los ves tú. Para que la vista sea común, el administrador la guarda para todos los empleados en los ajustes de la ficha: a partir de ahí todos tienen las mismas secciones y los ajustes personales dejan de divergir.
Una sección es un bloque con encabezado, y eso hace que una ficha larga se recorra con facilidad. Si necesitas un encabezado justo entre los campos de una misma sección, sin crear un bloque aparte, usa el campo personalizado «Separador de sección»: una línea fina con un título que no guarda nada y solo divide los campos en grupos. Así una sección larga «Sobre la negociación» gana estructura sin trocearla en cinco pequeñas.
¿Por qué un campo oculto sigue apareciendo en el filtro?
Ocultar un campo en la ficha solo cambia la ficha. El filtro, las columnas de la lista, la exportación a Excel, los informes, la API REST y los procesos de negocio siguen viendo el campo como antes. Por eso un campo que quitaste de la vista del comercial todavía se puede buscar en el filtro y mostrar como columna de la lista.
También es habitual el caso contrario: el campo está en la ficha, pero no aparece en el filtro. Hay dos motivos. Primero, cada empleado configura el filtro para sí mismo: el campo hay que añadirlo con «Añadir campo» dentro del propio filtro. Segundo, un campo personalizado tiene en sus ajustes la casilla «Mostrar en el filtro». Si está desactivada, el campo no saldrá en la lista de campos del filtro por mucho que lo busques. Una casilla parecida controla si el campo se muestra en la lista.
La conclusión práctica: ocultar es orden en la interfaz, no protección de datos. Los permisos de rol del CRM tampoco ayudan aquí: se conceden para el registro entero, no para un campo concreto. Si un valor de la ficha solo deben poder cambiarlo los administradores y algunos empleados elegidos, usa el campo «Valor bloqueado»: el resto lo ve en solo lectura. También es una protección de interfaz: las importaciones, REST y los procesos de negocio pueden seguir cambiando el valor, que es justo lo que necesita la automatización.
Lista de verificación
Oculta los campos poco frecuentes: configura la ficha, agrupa los campos en secciones, guarda la vista para todos. Comprueba qué campos hacen falta en el filtro y activa para ellos «Mostrar en el filtro». Activa la obligatoriedad por etapas para los campos de etapas concretas. Añade un robot de comprobación de combinaciones de campos en las transiciones entre etapas. Configura la autolimpieza de campos al cambiar el valor determinante. Los robots para este esquema están en el catálogo de Roboteka; ¿no hay el que necesitas? Describe la tarea, hacemos el robot gratis.