«Me dá acesso» chega como uma frase só e é resolvido de cinco jeitos diferentes: a um falta o papel no CRM, outro perdeu o campo «Responsável», o terceiro simplesmente não participa da tarefa. Enquanto o portal é pequeno, as permissões são distribuídas sob demanda. Com cinquenta pessoas isso vira um trabalho à parte, e a pergunta «quem enxerga esse negócio, afinal» deixa de ter resposta curta.

Como funcionam as permissões de acesso no Bitrix24?

Não existe um sistema único de permissões no portal — são três, e eles não se reduzem uns aos outros. O CRM funciona com modelo de papéis: papel mais nível de acesso, definido separadamente para ler, editar, excluir, exportar e importar. As tarefas não conhecem papéis; a visibilidade vem da participação — criador, responsável, participante, observador, membro do projeto. Grupos, Drive e o fluxo de atividades formam um terceiro modelo, com configurações próprias de privacidade. Ou seja, «dar acesso ao negócio e à tarefa dele» no Bitrix24 (Alaio) significa dois ajustes diferentes em dois lugares diferentes — e essa é a primeira razão pela qual o acesso é concedido e mesmo assim não funciona.

Como configurar as permissões do CRM?

A matriz fica nas configurações do CRM, na seção de permissões de acesso. Um papel é atribuído não só a uma pessoa, mas também a um departamento ou grupo — atribuir por departamento é a versão que sobrevive, porque quem entra herda os direitos no momento em que aparece na estrutura da empresa. Os níveis são os conhecidos: sem acesso, próprios, próprios e do departamento, próprios e dos subdepartamentos, todos. Eles valem por entidade e, em negócios e leads, também por etapa: dá para permitir a edição enquanto o negócio corre e congelá-lo depois de ganho.

Duas regras que poupam dor de cabeça. Mantenha poucos papéis: de três a cinco, ligados a departamentos em vez de um papel por pessoa, ou a matriz fica ilegível em menos de um ano. E trate a coluna de exportação como decisão separada: o nível «todos» com exportação ligada é o caminho pelo qual bases de clientes saem de um CRM.

Por que um funcionário não vê um negócio ou contato?

Nove em cada dez vezes o papel é inocente e o culpado é o campo «Responsável». O nível «próprios» significa literalmente «registros em que eu sou o responsável», então trocar o responsável tira o acesso do dono anterior na hora. O segundo caso mais comum: entidades vinculadas carregam permissões próprias, a pessoa vê o negócio mas não vê a empresa anexada, e o cartão parece pela metade embora os dados estejam lá. O terceiro: a marcação «disponível para todos» no cartão, que abre aquele registro específico por fora de toda a matriz.

Verifique nesta ordem: qual papel o usuário tem, qual nível vale para aquela entidade específica, quem é o responsável, em qual departamento ele consta na estrutura e se não é um usuário de extranet. O primeiro passo em que a resposta foge do esperado é a causa.

Quem enxerga uma tarefa e como dar acesso a ela?

Tarefas não têm papéis nem níveis. Uma tarefa é visível para o criador, o responsável, os participantes, os observadores, os membros do projeto ao qual ela pertence e para o gestor, nas tarefas de seus subordinados. É a lista inteira. Por isso «dar permissão em uma tarefa» tecnicamente não existe: a única entrada é incluir a pessoa como participante, normalmente como observador. O bloco Gerenciar observadores faz isso como etapa do processo — adiciona o gestor do departamento como observador quando o negócio entra em aprovação e o remove quando a aprovação termina.

Por que a automação enxerga um registro que a pessoa não vê?

Porque elas agem como identidades diferentes. As regras de automação nativas e as ações do processo rodam em nome de um usuário — quem criou a regra, ou o responsável — e esbarram exatamente nos limites dele: se a pessoa não vê o item, a ação também falha. Aplicativos instalados pelo Market funcionam de outro jeito: conversam com o portal usando o token que um administrador concedeu na instalação, então as atividades da Roboteka leem e gravam o registro independentemente de quem iniciou o processo.

Isso elimina uma classe inteira de falhas silenciosas e transfere um dever para você: como as permissões não vão barrar nada, a checagem de «essa pessoa pode?» pertence a uma condição dentro do processo, não à matriz de acesso. Se, por outro lado, o processo nem chegou a rodar, as permissões raramente são a causa — a ordem de diagnóstico está em por que os robôs não funcionam, e o lado das chamadas externas, no diagnóstico de webhooks.

Como manter o acesso em dia automaticamente?

Os papéis do CRM em si não dá para automatizar: a API REST não expõe métodos para editar a matriz de permissões, então ela continua sendo uma tela manual. O que dá para automatizar é tudo de que o acesso realmente depende — o responsável, o departamento e quem participa.

  • Obter o gestor do funcionário devolve o superior direto a partir da árvore de departamentos, para que uma etapa de aprovação aponte para um cargo e não para um nome fixo.
  • Obter o departamento do funcionário devolve o departamento do responsável, o que permite que um único modelo se ramifique por unidade em vez de criar um modelo por time.
  • Trocar o responsável nos vinculados transfere o responsável para negócios, contatos e empresas vinculados quando um cliente muda de mãos, para que o novo dono não herde meio cartão.

O que fazer em seguida

Comece por um inventário: liste os papéis realmente em uso e seus níveis sobre negócios — metade costuma ser duplicata. Depois feche a exportação onde ela não é necessária e mova a atribuição de papéis de pessoas para departamentos. Por fim, acrescente uma etapa que mantenha o responsável atualizado, porque é nesse único campo que se apoia a maior parte da visibilidade do CRM. Os demais blocos estão no catálogo de robôs, e o quadro completo, no guia de processos de negócio. Se o bloco de que você precisa não existir, descreva a tarefa: a Roboteka constrói as atividades que faltam de graça e as publica na biblioteca comum.