Criar uma pessoa e dar o acesso certo

O erro mais comum de quem começa não é errar um passo: é fazer só um deles. Criar a pessoa e parar por aí produz alguém que entra no produto e não vê nada; conceder permissão sem escopo produz alguém que vê a tela e não vê os dados. São quatro coisas diferentes, e todas precisam acontecer.

O que você faz	O que isso decide
Criar a pessoa	Que ela consegue entrar
Definir o papel	O piso hierárquico dela
Conceder permissão	Que áreas ela vê, e se pode editar
Amarrar o escopo	De quais setores ela vê os dados

O detalhe de cada eixo está em Permissões e papéis. Aqui é a ordem de execução.

Isto é tela de super administrador

IAM e Grupos exigem super_admin — não basta ter a permissão concedida. É piso de papel, imposto no servidor. Se você não enxerga esses itens no menu, é porque a sua conta não é super administrador, e nenhuma concessão resolve isso.

1. Os grupos vêm antes das pessoas

Administração → Grupos

Grupo, aqui, é setor — e é a unidade de escopo do produto inteiro: a fila de chamados, os ativos, a frota de máquinas. Criar as pessoas antes dos grupos funciona, mas obriga a voltar em cada uma para amarrar o escopo depois.

Comece com poucos: Suporte, Infraestrutura, Redes, o que existir de verdade. Setor a mais se cria em um minuto; chamado no setor errado dá trabalho de mover.

2. Criar a pessoa

Administração → IAM

Duas origens possíveis, e a escolha muda o que você faz depois:

Conta local — você cria, define a senha inicial e marca a troca obrigatória no primeiro acesso. Entrega segura: quem recebe a senha não continua com ela.

Diretório (LDAP ou Active Directory) — a pessoa não é criada aqui. Ela aparece no primeiro login bem-sucedido, e o papel vem dos grupos do diretório. Ver Autenticação: LDAP e TOTP.

Se você tem diretório, delegue a ele

O papel vindo do diretório é reavaliado a cada login: tirar alguém do grupo o rebaixa no próximo acesso, sem ninguém mexer no produto. É a diferença entre desligamento que fecha o acesso sozinho e desligamento que depende de alguém lembrar.

3. Escolher o papel

Quatro papéis, em ordem crescente — user, group_admin, admin, super_admin.

O que confunde: admin não é administrador da plataforma. É um papel elevado, e nada mais. Quem administra a plataforma é o super_admin, e é ele quem alcança IAM, Grupos, Configurações, Logs, Integrações e as três telas de Auditoria.

Para quem vai atender chamados, o papel user é suficiente. Papel resolve hierarquia; quem resolve acesso é a permissão.

4. Conceder a permissão

Cada permissão tem três níveis: nenhum, ver e editar. A concessão pode ser por pessoa ou por grupo, e o resultado é a união das camadas — com uma exceção que importa:

Negação explícita vence

Conceder editar no grupo e negar na pessoa resulta em negado. A união soma o que está concedido, mas uma negação explícita corta a cadeia. Quando alguém “tem permissão e não consegue”, procure a negação antes de procurar o bug.

Duas raízes já vêm liberadas e não precisam de concessão nenhuma:

• tickets em nível de ver — o portal de autoatendimento é para todo colaborador. Helpdesk em que a pessoa precisa de permissão para pedir ajuda não é helpdesk.
• mensageria em nível de editar — é o módulo em torno do qual o produto começou.

Então, na prática:

Quem	O que conceder
Só vai abrir chamado	Nada. Já está liberado.
Vai atender chamado	tickets em editar
Vai mexer no inventário	ativos em ver ou editar
Vai cuidar da frota de máquinas	manutencao — e manutencao.remoto só para quem realmente entra na máquina

Herança de sub-abas

Sub-aba herda do módulo. Pedir backups.restore sobe a cadeia até a primeira definição explícita — e essa primeira definição vence, inclusive quando ela é “nenhum”. É por isso que negar o módulo inteiro fecha as sub-abas sem que você precise negar uma a uma.

5. Amarrar o escopo

Permissão abre a tela. Escopo decide de quem são os dados dentro dela.

Quatro raízes são escopáveis por setor: tickets, ativos, manutencao e chatbots. A concessão de escopo usa a chave composta:

tickets:suporte
ativos:infraestrutura

Instalei e não aparece nada

É quase sempre isto. O escopo é imposto no servidor, não escondido na interface: um atendente sem setor não vê a fila vazia por engano — ele vê os próprios chamados, e nada além. Quem tem tickets:editar mas nenhum setor está exatamente nessa situação.

6. Conferir antes de entregar o acesso

Vale um minuto antes de avisar a pessoa que está liberado:

1. Ela entra?
2. Ela vê os itens de menu que deveria — e não vê os que não deveria?
3. Dentro do módulo, aparecem dados do setor dela?
4. Se for conta local: a troca de senha foi pedida no primeiro acesso?

O catálogo completo de permissões, com o que cada uma abre e quais exigem super administrador, está em Permissões e papéis.