Miembros y permisos
La pantalla Miembros responde "quién accede a la cuenta y qué puede hacer cada uno". Cada miembro tiene uno o más roles; cada role es un conjunto de permisos del catálogo del producto.
Invitar a alguien
Solo los administradores invitan a nuevos miembros. La invitación lleva el email, el nombre (opcional) y el role inicial (Operador, por defecto) y expira en 7 días. Al aceptar, la persona obtiene la cuenta ya con el role definido. Si el email ya pertenece a un usuario de la cuenta, o ya existe una invitación pendiente, el sistema la rechaza (USER_EXISTS / INVITATION_EXISTS).
:::note Requiere un proveedor de correo (SMTP) configurado El envío de la invitación por correo depende de un proveedor de correo transaccional (SMTP) provisionado en el ambiente. Mientras no esté configurado, la invitación se crea, pero el correo no se envía — el enlace debe llegar al invitado por otro medio. :::
Roles de sistema
Cuatro roles listos cubren la mayoría de las operaciones:
| Role | Qué puede |
|---|---|
| Administrador | Acceso total a todos los recursos. No puede ser removido. |
| Gestor | Gestión completa de la operación, sin administración de la cuenta (miembros, roles, claves de API, integraciones). |
| Operador | El día a día: clientes, cobros, tareas, acuerdos y disputas (lectura general + escritura operativa). |
| Visualizador | Solo lectura en todos los recursos. |
Los roles de sistema son inmutables (SYSTEM_ROLE_IMMUTABLE): cuando el producto gana permisos nuevos, pasan a valer automáticamente para esos roles, sin que necesites reconfigurar nada.
Roles personalizados
Además de los cuatro de sistema, puedes crear roles propios (vía POST /api/v1/team-roles) eligiendo cualquier combinación de permisos del catálogo. Los permisos desconocidos son rechazados; los nombres duplicados también (DUPLICATE). Un role personalizado en uso no puede ser eliminado (ROLE_IN_USE).
El catálogo de permisos
Todo permiso sigue el formato dunning.dashboard.<recurso>.<ação>, con soporte de comodín (dunning.dashboard.*). Recursos y acciones reales:
| Recurso | Acciones |
|---|---|
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 |
El mismo catálogo alimenta los alcances (scopes) de las claves de API.
Asignar roles y desactivar miembros
En la tabla de miembros (nombre, roles, último acceso, estado Activo/Inactivo), el ícono de edición abre el selector de roles. El cambio rige de inmediato y cierra la sesión actual del miembro — tiene que entrar de nuevo, ya con los permisos nuevos. Desactivar a un miembro corta el acceso al instante, sin borrar su historial en la auditoría.
Protecciones contra errores costosos
LAST_ADMIN: el sistema se niega a degradar o desactivar al último administrador activo (nadie deja su propia cuenta cerrada por fuera).SELF_DEACTIVATION: no puedes desactivar tu propia cuenta.SELF_ROLE_CHANGE: los no administradores no alteran su propio role.
Todo cambio de miembro y role queda registrado en la auditoría.