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).
:::tip El mismo email puede participar en varias organizaciones Invitar a alguien que ya usa Dunning en otra organización funciona con normalidad: al aceptar, la persona obtiene un acceso separado en tu cuenta (roles y permisos propios, sin mezclar nada entre organizaciones). Al iniciar sesión, quien participa en más de una organización elige a cuál entrar y puede cambiar en cualquier momento con el selector en la parte superior de la pantalla, sin cerrar sesión. :::
:::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
Cinco roles listos cubren la mayoría de las operaciones:
| Role | Qué puede |
|---|---|
| Propietario | Acceso total (*), incluso a los permisos que el producto gane después. Quien crea la cuenta nace propietario; solo un propietario vuelve propietaria a otra persona. |
| Administrador | Administración completa de la cuenta — todos los permisos del catálogo, excepto borrar workspaces (workspaces.delete), que queda con el propietario. |
| 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 cinco de sistema, puedes crear roles propios (vía POST /v1/team-roles) eligiendo cualquier combinación de permisos del catálogo. Los permisos desconocidos son rechazados; los nombres duplicados también (DUPLICATE). Nadie crea ni edita un role con permisos que no tiene — el intento responde 403 con la lista de lo que falta (beyondCeiling). Un role personalizado en uso no puede ser eliminado (ROLE_IN_USE).
El catálogo de permisos
Todo permiso sigue el formato <recurso>.<acción> — el recurso en kebab-case cuando es compuesto (collection-rules.activate) —, con soporte de comodín: * (todo) o <recurso>.* (todas las acciones de un recurso del catálogo). La lectura es siempre list, show o download. Recursos y acciones reales:
| Recurso | Acciones |
|---|---|
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 |
El mismo catálogo alimenta los permisos de las claves de API — que no son los scopes del token de la API, un vocabulario separado y más grueso (ver Autenticación).
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_OWNER: el sistema se niega a quitarle el role de propietario al último propietario activo, o a desactivarlo (nadie deja su propia cuenta cerrada por fuera).- Techo de permisos: nadie concede — por role, por permiso directo o por invitación — más de lo que tiene. Un comodín solo lo concede quien tiene un comodín igual de amplio; por eso solo el propietario concede el role de propietario.
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.