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, 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.

Lista de verificación

Oculta los campos poco frecuentes: configura la ficha, agrupa los campos en secciones, guarda la vista para todos. 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.