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).
:::tip O mesmo e-mail pode participar de várias organizações Convidar alguém que já usa o Dunning em outra organização funciona normalmente: ao aceitar, a pessoa ganha um acesso separado na sua conta (roles e permissões próprios, sem misturar nada entre organizações). No login, quem participa de mais de uma organização escolhe em qual entrar e pode trocar a qualquer momento pelo seletor no topo da tela, sem sair e entrar de novo. :::
:::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
Cinco roles prontos cobrem a maioria das operações:
| Role | O que pode |
|---|---|
| Proprietário | Acesso total (*), inclusive às permissões que o produto ganhar depois. Quem cria a conta nasce proprietário; só um proprietário torna outra pessoa proprietária. |
| Administrador | Administração completa da conta — todas as permissões do catálogo, exceto apagar workspaces (workspaces.delete), que fica com o proprietário. |
| 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 cinco de sistema, você pode criar roles próprios (via POST /v1/team-roles) escolhendo qualquer combinação de permissões do catálogo. Permissões desconhecidas são rejeitadas; nomes duplicados também (DUPLICATE). Ninguém cria nem edita um role com permissões que não tem — a tentativa responde 403 com a lista do que falta (beyondCeiling). 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 <recurso>.<ação> — recurso em kebab-case quando composto (collection-rules.activate) —, com suporte a curinga: * (tudo) ou <recurso>.* (todas as ações de um recurso do catálogo). Leitura é sempre list, show ou download. Recursos e ações reais:
| Recurso | Ações |
|---|---|
dashboard | show |
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 |
companies | 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 |
workspaces | list, create, update, delete |
notification-channels | show, update |
notification-preferences | show, update |
O mesmo catálogo alimenta as permissões das chaves de API — que não são os escopos do token da API, um vocabulário separado e mais grosso (ver Autenticação).
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_OWNER: o sistema recusa tirar o role de proprietário do último proprietário ativo, ou desativá-lo (ninguém tranca a própria conta por fora).- Teto de permissões: ninguém concede — por role, por permissão direta ou por convite — mais do que tem. Um curinga só é concedido por quem tem curinga igualmente amplo; por isso só o proprietário concede o role de proprietário.
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.