Perfis e permissões

O controle de acesso do ZAAZ BI tem duas camadas que operam de forma independente. Confundi-las é a origem de praticamente todo problema de permissão.

Em uma frase: a função é a chave-geral — Administrador faz tudo; qualquer outra função não concede nada por si só. O perfil de acesso é o painel detalhado, e só entra em jogo para quem não é Administrador.

As duas camadas

Função (o campo Função no cadastro do usuário; chamada papel base no resto deste artigo). No formulário há duas opções, Colaborador e Administrador, e só um administrador pode defini-la.

Perfil de acesso — o registro criado em Administração › Perfis, com permissões detalhadas por módulo.

A relação entre elas é simples e absoluta:

Se a função é admin (Administrador), a verificação de permissão retorna verdadeiro antes de olhar qualquer perfil de acesso.

Um administrador com o perfil mais restritivo possível continua enxergando e fazendo tudo dentro da organização dele. Para limitar alguém de verdade, a função precisa ser diferente de Administrador.

Sem perfil de acesso atribuído e sem ser Administrador, a pessoa fica sem nenhuma permissão — vê apenas os dashboards.

As funções, uma a uma

Função	Como se concede	O que dá	Na lista de colaboradores
Colaborador (user)	padrão de todo cadastro	nada por si só — o acesso vem do perfil de acesso atribuído	”Colaborador”
Administrador (admin)	escolha manual; só outro administrador concede	controle total da organização; ignora perfil e expediente; sempre exporta dados; cria outros administradores	”Admin”
manager	valor legado, não aparece no formulário	nada — hoje é tratado exatamente como Colaborador	”Colaborador”
super admin	ligado direto no banco, sem tela	flag herdada do produto multiempresa; onde ainda é consultada, age como Administrador	não aparece

Para a operação do dia a dia só as duas primeiras importam. “Líder (Gestor)” no cadastro é outra coisa — aponta o chefe da pessoa para montar o organograma, não é função.

Isso não quer dizer que um perfil de acesso sem admin seja só cosmético — para as permissões listadas em como a permissão é aplicada, marcar a caixa realmente libera a ação, não só o item no menu. A confusão entre “papel base” e “perfil de acesso” já causou o problema oposto também: alguém monta um perfil chamado “Administrador”, marca tudo, atribui a duas pessoas — e elas continuam sendo barradas em ações que ainda dependem exclusivamente do papel base (ver a lista logo abaixo). Ver erros comuns.

As abas do perfil

Geral

Nome, descrição e cor de identificação. Aqui também ficam os papéis do Power BI — os nomes das roles definidas no modelo de dados do relatório, usados quando o relatório aplica segurança em nível de linha.

Desde 2026-09-04, também tem o campo Expediente de Acesso: restringe em que dias e horários quem tem este perfil pode entrar na plataforma. Cadastrado à parte, em Organização › Expedientes — ver expedientes de acesso para como funciona (inclusive por que é atribuído só ao perfil, não ao usuário individual).

Permissões

Uma grade de módulos contra as ações ver, criar, editar e inativar:

• Usuários
• Processos
• Indicadores
• Perfis de acesso
• Contratos
• CRM

A coluna antes chamada excluir passou a se chamar inativar (2026-09-11). A plataforma não apaga registros importantes — usuários, perfis, cargos, setores, departamentos só são inativados, para preservar histórico e vínculos. A caixa marcada libera a ação de inativar.

Processos, Indicadores e CRM estão fora de uso nesta instância (decisão de 2026-08-31) — os campos de permissão continuam na tela porque o formulário não foi alterado, mas não há tela nenhuma que respeite essa permissão hoje.

Além da grade, três controles à parte:

CRM administrativo — ver todas as vendas, gerenciar e configurar o módulo (mesma ressalva acima: módulo fora de uso).

Gerenciar configurações da organização — a permissão mais poderosa da lista, mas não é sinônimo de “libera a área /admin inteira” (era isso que este artigo dizia até 2026-09-03 — não era verdade, ver como a permissão é aplicada para o que ela cobre de fato). Conceda com o mesmo critério com que se concede admin.

Exportar dados — controla se a pessoa pode extrair dados dos relatórios do Power BI. Pode vir do perfil ou de um campo individual no cadastro; qualquer um dos dois habilita.

Cargos

Vincula o perfil a cargos. Serve para padronizar: pessoas de determinado cargo recebem o perfil correspondente.

Dashboards

Seleciona quais dashboards este perfil enxerga. É o filtro da barra lateral do módulo de Dashboards.

Como a permissão é aplicada

A verificação acontece em três lugares, e é importante saber o que cada um garante:

No menu — itens sem permissão não são exibidos.

Na rota — abrir a URL diretamente sem permissão redireciona para /dashboard. Vale para /users, /indicators, /processes e /admin.

No banco de dados / na API — algumas ações verificam a mesma configuração de permissões antes de executar; outras ainda checam só o papel base (admin), não a permissão granular.

As duas primeiras camadas são de interface e rodam no navegador — sozinhas, nunca protegem dado nenhum, só escondem botão. A terceira é a que decide de verdade se a ação acontece. Até 2026-09-03 este artigo dizia que a terceira camada sempre respeitava a permissão granular — não era verdade. A tabela abaixo é o estado real, ação por ação:

Ação	Verifica permissão granular?
Editar dados da empresa (/admin/company)	Sim — organization.manage_settings
Domínios corporativos, Menus, Dashboards, Templates de e-mail, Power BI/Configurações	Sim — organization.manage_settings (corrigido em 2026-09-03)
Adicionar usuário como Colaborador	Sim — users.create (corrigido em 2026-09-03)
Adicionar usuário já como Administrador	Não — mesmo com users.create marcado, só quem já é Administrador cria outro
Editar um usuário existente — dados, vínculo organizacional, perfil de acesso, ativar/inativar	Sim — users.edit (corrigido em 2026-09-11)
Alterar a função (Administrador/Colaborador) de um usuário	Não — exige Administrador de verdade, mesmo com users.edit marcado
Reenviar e-mail de boas-vindas/redefinição, ativação manual	Não — exige Administrador de verdade
Criar ou editar perfis de acesso (esta própria tela), atribuir dashboards a um perfil	Não, de propósito — perfil não pode se auto-conceder mais permissão do que um admin configurou; ver nota abaixo
Auditoria, Migração de dados, Sincronização Voors, envio de e-mail em massa	Não — exige Administrador de verdade
Processos, Indicadores, CRM	Sem efeito nenhum — módulos fora de uso, nenhuma tela consulta essas permissões

Perfis de acesso e a atribuição de dashboards a eles ficam de fora de propósito: se organization.manage_settings liberasse editar perfis, alguém com esse único checkbox poderia criar um perfil com tudo marcado e se atribuir a ele — uma forma de auto-promoção pela borda do próprio sistema de permissões. Continuam exigindo admin real.

Erros comuns

Alguém restrito enxergando tudo — a função está como Administrador. Verifique o campo Função no cadastro da pessoa, não o perfil de acesso.

Alguém sem enxergar nada — não há perfil de acesso atribuído. Sem perfil e sem ser Administrador, todas as permissões ficam negadas.

Dashboard não aparece para um perfil — falta selecioná-lo na aba Dashboards do perfil.

Perfil com tudo marcado, e a pessoa vê a tela mas a ação falha (erro tipo “Unauthorized” ou “row-level security policy”) — a tela abriu porque o menu respeitou a permissão granular, mas a ação em si ainda pode ser uma das que exigem admin de verdade, não só a permissão marcada. Confira na tabela em como a permissão é aplicada se aquela ação específica já foi conectada à permissão granular. Se não foi, a pessoa precisa do papel base admin, e o perfil de acesso configura o resto (menus, dashboards, exportação).

Permissão alterada e nada mudou — a interface guarda em cache a visibilidade do menu para evitar piscar a tela a cada carregamento. Peça para a pessoa sair e entrar novamente. As permissões efetivas no banco são recalculadas sempre; o cache afeta só o que o menu exibe.