«Dame acceso» llega como una sola frase y se arregla de cinco maneras distintas: a uno le falta el rol de CRM, otro ha perdido el campo «Responsable», el tercero simplemente no participa en la tarea. Mientras el portal es pequeño, los permisos se reparten a petición. Con cincuenta empleados eso se convierte en un trabajo aparte, y la pregunta «quién ve realmente este negocio» deja de tener respuesta corta.

¿Cómo funcionan los permisos de acceso en Bitrix24?

No hay un único sistema de permisos en el portal: hay tres, y no se reducen entre sí. El CRM funciona con un modelo de roles: rol más nivel de acceso, definido por separado para leer, editar, eliminar, exportar e importar. Las tareas no saben nada de roles; la visibilidad nace de la participación: creador, responsable, participante, observador, miembro del proyecto. Grupos, Drive y el flujo de actividad forman un tercer modelo con sus propios ajustes de privacidad. Así que «dar acceso al negocio y a su tarea» en Bitrix24 (Alaio) significa dos ajustes distintos en dos sitios distintos, y esa es la primera razón por la que se concede acceso y aun así no funciona.

¿Cómo configurar los permisos del CRM?

La matriz vive en los ajustes de CRM, en la sección de permisos de acceso. Un rol se asigna no solo a una persona, sino también a un departamento o a un grupo, y la asignación por departamento es la que sobrevive, porque quien se incorpora hereda sus derechos en cuanto aparece en la estructura de la empresa. Los niveles son los de siempre: sin acceso, propios, propios y del departamento, propios y de los subdepartamentos, todos. Se definen por entidad y, en negocios y leads, también por etapa: se puede permitir la edición mientras el negocio está en curso y congelarlo cuando se gana.

Dos reglas que ahorran disgustos. Mantén pocos roles: de tres a cinco, ligados a departamentos en lugar de un rol por persona, o la matriz será ilegible en menos de un año. Y trata la columna de exportación como una decisión propia: el nivel «todos» con exportación activada es la vía por la que las bases de clientes salen de un CRM.

¿Por qué un empleado no ve un negocio o un contacto?

Nueve de cada diez veces el rol es inocente y el culpable es el campo «Responsable». El nivel «propios» significa literalmente «registros en los que soy responsable», así que cambiar el responsable retira el acceso al dueño anterior de inmediato. El segundo caso más común: las entidades vinculadas llevan sus propios permisos, alguien ve el negocio pero no la empresa asociada, y la ficha parece medio vacía aunque los datos estén ahí. El tercero: la marca «disponible para todos» en la ficha, que abre ese registro concreto saltándose toda la matriz.

Comprueba en este orden: qué rol tiene el usuario, qué nivel aplica a esa entidad concreta, quién es el responsable, en qué departamento figura dentro de la estructura y si no será un usuario de extranet. El primer paso en el que la respuesta se desvía de lo esperado es la causa.

¿Quién ve una tarea y cómo se da acceso a ella?

Las tareas no tienen roles ni niveles. Una tarea la ven su creador, el responsable, los participantes, los observadores, los miembros del proyecto al que pertenece y el superior, en las tareas de sus subordinados. Esa es la lista completa. Por eso «dar permisos sobre una tarea» no existe técnicamente: la única entrada es añadir a la persona como participante, normalmente como observador. El bloque Gestionar observadores lo hace como paso del proceso: añade al jefe de departamento como observador cuando el negocio entra en aprobación y lo retira cuando la aprobación termina.

¿Por qué la automatización ve un registro que una persona no ve?

Porque actúan con identidades distintas. Las reglas de automatización nativas y las acciones de proceso se ejecutan en nombre de un usuario —quien creó la regla, o el responsable— y chocan exactamente con sus límites: si la persona no ve el elemento, la acción también falla. Las aplicaciones instaladas desde el Market funcionan de otro modo: hablan con el portal mediante el token que un administrador concedió durante la instalación, de modo que las actividades de Roboteka leen y escriben el registro sin importar quién inició el proceso.

Eso elimina toda una clase de fallos silenciosos y traslada un deber a tu lado: como los permisos ya no detendrán nada, la comprobación de «si esta persona puede» pertenece a una condición dentro del proceso y no a la matriz de acceso. Si en cambio el proceso no llegó a arrancar, los permisos rara vez son el culpable: el orden de diagnóstico está en por qué no funcionan los robots, y el lado de las llamadas externas, en el diagnóstico de webhooks.

¿Cómo mantener el acceso al día automáticamente?

Los roles de CRM en sí no se pueden automatizar: la API REST no expone métodos para editar la matriz de permisos, así que sigue siendo una pantalla manual. Lo que sí se automatiza es todo aquello de lo que el acceso depende de verdad: el responsable, el departamento y quién participa.

  • Obtener el superior del empleado devuelve el jefe directo desde el árbol de departamentos, para que un paso de aprobación apunte a un cargo y no a un nombre escrito a mano.
  • Obtener el departamento del empleado devuelve el departamento del responsable, lo que permite que una sola plantilla se ramifique por unidad en vez de crear una plantilla por equipo.
  • Cambiar el responsable en los vinculados traslada al responsable a negocios, contactos y empresas vinculados cuando un cliente cambia de manos, para que el nuevo dueño no herede media ficha.

Qué hacer a continuación

Empieza por una auditoría: anota los roles que se usan de verdad y sus niveles sobre negocios; la mitad suelen ser duplicados. Después cierra la exportación donde no haga falta y traslada la asignación de roles de las personas a los departamentos. Por último, añade un paso que mantenga al responsable actualizado, porque ese único campo sostiene casi toda la visibilidad del CRM. El resto de bloques están en el catálogo de robots, y el panorama completo, en la guía de procesos de negocio. Si falta el bloque que necesitas, describe la tarea: Roboteka crea las actividades que faltan de forma gratuita y las publica en la biblioteca común.