Guias

Usuários e papéis

RBAC do Interaflow é por papel fixo. Cada User tem um único papel que decide o que vê e pode fazer; não há permissões nominais por recurso.

Atualizado em 04 de maio de 2026

O que é

A área de Usuários é onde você cadastra, edita, ativa, desativa e atribui papéis às pessoas que vão entrar no Interaflow do seu tenant. O modelo de autorização é simples por desenho: cada User tem um papel único, e o papel decide o que ele vê e pode fazer.

Não existem permissões nominais por recurso (“pode editar Campanha”, “pode ver Conversa”) — a granularidade é por papel, não por ação. Se a sua operação precisa de permissões mais finas, fale com o time Interaflow para alinhar o caminho — é decisão consciente, não limitação técnica.

Papéis disponíveis

O Role é um enum fixo de seis valores. Os nomes técnicos divergem da copy de UI em alguns casos — o que importa é o papel real:

Role (técnico)	UI / copy	Significado
superuser	Superuser	Operação Interaflow. Atravessa tenants, configura recursos globais.
admin	Admin	Admin do tenant. Cadastra usuários, configura Operações, Campanhas, integrações.
supervisor	Supervisor	Acompanha operação, gerencia Filas, atua em Qualidade. Pode atender.
cliente	Cliente	Usuário externo do tenant. Mesmo nível de Supervisor (acesso de leitura/operação leve).
member	Membro	Usuário básico do tenant. Acesso restrito ao essencial.
agente	Atendente	Pessoa humana que atende Conversas. Tem perfil de atendimento e credencial de Voz.

Modelo de campos do User

Cada User cadastrado tem:

E-mail (único globalmente). É a chave de login e a identidade.
Papel (Role) — único, escolhido entre os seis.
Senha (hash) — opcional. Nulo quando o User foi criado via SSO Google e nunca cadastrou senha local.
Ativo (is_active) — quando false, login é bloqueado imediatamente.
Tenant ao qual pertence (tenant_id). Superuser não tem tenant — é cross-tenant.
Provedor de autenticação (auth_provider) — password ou google.
google_sub — claim estável retornada pelo Google quando o User entrou via SSO. Vinculada na primeira autenticação.
Modo desenvolvedor (is_developer) — flag para ver informações de debug (montagem de prompt, logs detalhados). Apenas superuser pode ativar para outros usuários.

Soft delete via deleted_at — usuários “excluídos” somem da UI mas o registro permanece para auditoria histórica.

Cadastrar um novo User

Em Configurações → Usuários, clique em adicionar e preencha:

E-mail — único; não pode coincidir com nenhum outro User do sistema.
Papel — escolha entre os seis. Limita o que a pessoa vai ver e fazer no dashboard.
Senha inicial — opcional. Se você usa SSO Google, pode deixar em branco; o User só conseguirá entrar via Google.
Tenant — preenchido automaticamente com o tenant atual (superuser pode trocar).

Ao salvar, o User aparece na lista. A primeira autenticação — seja por senha ou por Google — completa o cadastro de fato (no SSO Google, a vinculação google_sub ↔ User acontece na primeira entrada).

SSO e fallback

A combinação de senha local + Google funciona em coexistência quando o tenant tem SSO Google habilitado:

User pode entrar por qualquer um dos dois se ambos estiverem cadastrados.
User criado via SSO Google e que nunca cadastrou senha local fica restrito a SSO.
Tenant pode forçar só SSO (sso_only) — bloqueia login por senha exceto para superuser. Detalhes em SSO com Google Workspace.

Convidar X cadastrar diretamente

A página atual cadastra User direto (você define a senha inicial ou autoriza login via SSO Google). Convite por e-mail com link de ativação não é o fluxo principal hoje — costuma-se cadastrar e comunicar a credencial à pessoa por canal interno (Slack, Teams, e-mail manual).

Permissões efetivas por papel

Como o RBAC é por papel, vale fixar a percepção prática:

Capacidade	Atendente	Supervisor / Cliente	Admin	Superuser
Atender Conversas	✅	✅	✅	✅
Acompanhar Conversas alheias	—	✅	✅	✅
Configurar Campanhas, Fluxos, Filas	—	parcial	✅	✅
Cadastrar / desativar Users	—	—	✅	✅
Configurar SSO, integrações, OpenAI	—	—	✅	✅
Acesso ao app mobile	conforme Acesso Mobile	conforme Acesso Mobile	conforme Acesso Mobile	conforme Acesso Mobile
Atravessar tenants	—	—	—	✅
Modo desenvolvedor (debug)	—	—	só se ativado por superuser	✅
Configurar Perfis de Classificação	—	—	—	✅

A coluna “parcial” para supervisor/cliente reflete que essas páginas existem para esses papéis em modo de leitura/operação leve, não com poder de configuração total.

Desativar / reativar

A desativação é o caminho preferido para “tirar acesso”. Em vez de excluir o User:

Desative (is_active = false) — login é bloqueado imediatamente, mas o histórico (Conversas atendidas, avaliações, etc.) fica preservado e atribuído ao User correto.
Para reativar, volte na lista e ative novamente.

A exclusão (soft delete) é mais rara — útil quando a pessoa saiu definitivamente e você quer remover da lista de Users “correntes”. O registro permanece no banco com deleted_at populado.

Boas práticas

Use o papel mais restrito possível. “Cliente” e “Member” cobrem boa parte dos casos de “vê dashboard mas não toca em nada”.
Reserve superuser para a operação Interaflow. Não dê superuser para admins de cliente — a regra padrão é admin do tenant.
Cadastre Atendente com e-mail real. A credencial de Voz depende do User; e-mail compartilhado complica auditoria.
Combine com SSO sempre que a empresa tem Workspace. Reduz surface de senha vazada e simplifica offboarding.
Audite usuários inativos periodicamente. Conta esquecida ativa é vetor desnecessário de risco.

Limites conhecidos

Sem permissões granulares. Um Atendente não pode ver “só as Conversas dele” via permissão — isso é comportamento padrão do papel.
Sem multi-papel por User. Um User é Atendente OU Supervisor — não os dois ao mesmo tempo. Para casos híbridos, escolha o papel mais permissivo.
Sem fluxo formal de convite por e-mail com link de ativação.
Sem MFA nativo. A defesa adicional vem do SSO Google (que pode exigir MFA pela política do Workspace).

Erros comuns

Cadastrar Atendente como Member esperando que ele entre na tela de Comunicação. Atendente é o papel certo — Member não tem perfil de atendimento.
Excluir em vez de desativar. Quebra reuso futuro; perde contexto histórico na UI corrente.
Esquecer de desativar User de pessoa que saiu. Vetor de risco. Inclua no offboarding da empresa.
Tentar criar User com e-mail já cadastrado em outro tenant. E-mail é único globalmente — não pode repetir.