Membros e permissões
A tela Membros responde "quem acessa a conta e o que cada um pode fazer". Cada membro tem um ou mais roles; cada role é um conjunto de permissões do catálogo do produto.
Convidar alguém
Apenas administradores convidam novos membros. O convite carrega o e-mail, o nome (opcional) e o role inicial (Operador, por padrão) e expira em 7 dias. Ao aceitar, a pessoa ganha a conta já com o role definido. Se o e-mail já pertence a um usuário da conta, ou já existe convite pendente, o sistema recusa (USER_EXISTS / INVITATION_EXISTS).
:::note Requer provedor de e-mail (SMTP) configurado A entrega do convite por e-mail depende de um provedor de e-mail transacional (SMTP) provisionado no ambiente. Enquanto isso não estiver configurado, o convite é criado, mas o e-mail não é enviado — o link precisa chegar ao convidado por outro meio. :::
Roles de sistema
Quatro roles prontos cobrem a maioria das operações:
| Role | O que pode |
|---|---|
| Administrador | Acesso total a todos os recursos. Não pode ser removido. |
| Gestor | Gestão completa da operação, sem administração da conta (membros, roles, chaves de API, integrações). |
| Operador | Dia a dia: clientes, cobranças, tarefas, acordos e disputas (leitura geral + escrita operacional). |
| Visualizador | Somente leitura em todos os recursos. |
Roles de sistema são imutáveis (SYSTEM_ROLE_IMMUTABLE): quando o produto ganha permissões novas, elas passam a valer automaticamente para esses roles, sem você precisar reconfigurar nada.
Roles customizados
Além dos quatro de sistema, você pode criar roles próprios (via POST /api/v1/team-roles) escolhendo qualquer combinação de permissões do catálogo. Permissões desconhecidas são rejeitadas; nomes duplicados também (DUPLICATE). Um role custom em uso não pode ser excluído (ROLE_IN_USE).
O catálogo de permissões
Toda permissão segue o formato dunning.dashboard.<recurso>.<ação>, com suporte a curinga (dunning.dashboard.*). Recursos e ações reais:
| Recurso | Ações |
|---|---|
dashboard | view |
people | list, show, create, update, delete |
charges | list, show, create, update, delete, notify |
collection_rules | list, show, create, update, delete, activate |
classifications | list, show, create, update, delete |
templates | list, show, create, update, delete, duplicate |
notifications | list, show, create, update, resend, delete |
tasks | list, show, create, update, delete, complete |
interactions | list, show, create, update, delete |
agreements | list, show, create, update, cancel |
disputes | list, show, create, resolve |
negativations | list, show, create, approve, cancel |
protests | list, show, create, approve, cancel |
portal | generate_link, revoke_link |
workspaces | list, manage |
members | list, show, invite, update, suspend, remove |
roles | list, show, create, update, delete, assign |
audit | list, show |
api_keys | list, create, revoke |
integrations | list, manage |
webhooks | list, show, create, update, delete |
email_layouts | list, show, create, update, delete |
imports | list, show, create |
exports | create |
settings | show, update |
O mesmo catálogo alimenta os escopos das chaves de API.
Atribuir roles e desativar membros
Na tabela de membros (nome, roles, último acesso, status Ativo/Inativo), o ícone de edição abre o seletor de roles. A mudança vale imediatamente e encerra a sessão atual do membro — ele precisa entrar de novo, já com as permissões novas. Desativar um membro corta o acesso na hora, sem apagar o histórico dele na auditoria.
Proteções contra tiro no pé
LAST_ADMIN: o sistema recusa rebaixar ou desativar o último administrador ativo (ninguém tranca a própria conta por fora).SELF_DEACTIVATION: você não pode desativar a própria conta.SELF_ROLE_CHANGE: não-admins não alteram o próprio role.
Toda mudança de membro e role fica registrada na auditoria.