Una invitación de usuario parece un correo con un enlace, pero en un SaaS B2B es un flujo de identidad y pertenencia a una organización. Si no se define qué ocurre cuando el enlace caduca, se reenvía o llega a una cuenta existente, el equipo acaba resolviendo excepciones manualmente y los usuarios reciben resultados difíciles de entender.
La decisión de producto consiste en modelar el ciclo completo, no solo el envío. Conviene separar la invitación —una solicitud pendiente para un correo y una organización— de la cuenta de usuario y de los permisos que tendrá al incorporarse. Ese límite ayuda a diseñar un proceso predecible, auditable y seguro.
Modela la invitación con estados y transiciones explícitos
Empieza por definir los estados que necesita el producto. Un modelo habitual incluye pendiente, aceptada, caducada y revocada. Si el envío de correo puede fallar de manera observable, registra ese resultado aparte o añade un estado operativo, como «envío fallido». No conviertas cada problema de entrega en un estado de negocio si el usuario aún puede aceptar la invitación.
Especifica qué acciones permiten las transiciones. Una invitación pendiente puede aceptarse, revocarse o caducar; una caducada puede reemplazarse por una nueva; una aceptada ya no debe volver a aceptarse. La revocación debe impedir el uso del enlace, aunque el mensaje original siga en la bandeja de entrada.
- Identifica el objeto: guarda la organización, la dirección invitada, quién la creó y cuándo.
- Define el resultado: registra la aceptación y la identidad que completó el proceso.
- Evita estados ambiguos: «correo enviado» no significa necesariamente «invitación aceptada» ni garantiza que el mensaje se haya leído.
Esta separación también facilita explicar la pantalla de administración: quién está pendiente, desde cuándo y qué puede hacer el administrador a continuación.
Decide la caducidad según el riesgo y la experiencia
La caducidad limita durante cuánto tiempo puede usarse un enlace. Una invitación demasiado duradera amplía la ventana para que un enlace reenviado o expuesto siga siendo válido; una demasiado breve genera fricción, especialmente si la persona invitada consulta el correo días después. No hay una duración universal: depende del riesgo, del tipo de organización y de cuánto control necesite el administrador.
Define de forma consistente qué sucede al vencer. La opción más clara suele ser mostrar que la invitación ya no es válida y ofrecer un camino para solicitar otra. Si el usuario tiene sesión iniciada, puedes orientar ese paso hacia el administrador de la organización. No presentes una invitación caducada como si la cuenta estuviera bloqueada: son situaciones diferentes.
En la interfaz de quien invita, muestra la fecha de vencimiento o el estado caducado y permite generar una invitación nueva si tiene autorización. Determina también si la nueva invitación conserva el destino y el rol previsto o si el responsable debe revisarlos. La caducidad debe ser una regla de servidor, no solo un temporizador visual: el sistema tiene que comprobarla al aceptar.
Diseña reenvíos y cambios de correo sin rescatar enlaces antiguos
Un reenvío puede significar dos cosas distintas: volver a enviar el mismo enlace o emitir uno nuevo. Si se conserva el enlace, la fecha de vencimiento y el token siguen igual. Si se genera otro, define explícitamente si el anterior queda invalidado. Para evitar que haya varias rutas activas hacia una misma invitación, suele ser más sencillo revocar el token previo al emitir el nuevo.
El usuario que invita necesita confirmación de que la acción se completó y una señal clara si el envío falla. Evita que un botón de reenvío cree invitaciones independientes cada vez que se pulsa: aplica una regla de idempotencia o comprueba si ya existe una invitación pendiente equivalente. También conviene prevenir envíos repetidos accidentales sin bloquear una nueva tentativa legítima.
Si cambia la dirección, trata el cambio como una modificación sensible. La solución más clara suele ser revocar la invitación dirigida al correo anterior y crear otra para el nuevo. No cambies silenciosamente el destinatario manteniendo un enlace que ya se envió: quien controle el buzón antiguo podría conservar acceso al proceso. Registra el cambio para que la organización pueda entender qué ocurrió.
Resuelve duplicados y cuentas que ya existen
Antes de crear una invitación, define qué significa que sea duplicada. Una regla práctica es considerar la combinación de organización y dirección normalizada, con las mismas convenciones de normalización en todo el sistema. No apliques transformaciones agresivas a direcciones de correo: algunas equivalencias que parecen obvias no son universales. Conserva la dirección que el usuario introdujo para mostrarla y para el envío.
Si ya existe una invitación pendiente para esa organización y correo, ofrece una acción útil: mostrar el estado, reenviar o revocar y reemplazar, según los permisos del actor. No crees una segunda entrada que deje a los administradores sin saber cuál es válida.
Si el correo pertenece a una cuenta existente, la invitación puede añadir esa identidad a otra organización, siempre que la persona se autentique con la cuenta correcta y acepte la incorporación. Una cuenta existente no equivale a pertenecer a todas las organizaciones. Si hay varias cuentas que pueden asociarse al mismo correo, no las enlaces automáticamente sin un mecanismo de verificación y una regla de identidad definida.
Protege el enlace y verifica quién lo acepta
El enlace debe funcionar como una credencial temporal. Usa un token difícil de adivinar, asociado a una invitación concreta y con una caducidad comprobada en el servidor. No incluyas información sensible en la URL y evita exponer el token en registros, analítica o páginas de terceros. Las recomendaciones de OWASP sobre gestión segura de credenciales y sesiones sirven como referencia para revisar el diseño.
Al abrir el enlace, muestra suficiente contexto para que la persona entienda a qué organización se incorpora y con qué dirección fue invitada. Antes de completar la aceptación, verifica que controla ese correo. Si ya ha iniciado sesión con otra identidad, explica el conflicto y solicita que cambie de cuenta o complete la verificación, en vez de vincular ambas identidades por conveniencia.
La aceptación debe ser una operación atómica: comprobar que la invitación sigue pendiente y vigente, confirmar la identidad, crear la pertenencia y marcar la invitación como aceptada. Si dos solicitudes intentan consumir el mismo enlace a la vez, solo una debe completar el cambio. Una segunda visita puede mostrar que la invitación ya se utilizó, sin volver a conceder acceso.
Fija qué ocurre si cambian permisos o se revoca
La invitación puede incluir un rol inicial o una referencia a permisos que se aplicarán al aceptar. Decide si esos permisos se fijan al enviar o se consultan al aceptar. Fijarlos hace explícita la oferta original; consultarlos al final permite reflejar cambios recientes, pero puede sorprender a quien invitó. En ambos casos, informa de cambios relevantes y evita ampliar permisos sin una decisión deliberada.
Si se revoca antes de la aceptación, el enlace debe dejar de funcionar y la persona invitada debe recibir un mensaje neutro que explique que ya no puede completar ese proceso. No reveles información innecesaria sobre la organización. Si se modifican el rol o el correo, registra quién hizo el cambio y cuándo, especialmente cuando varias personas administran la organización.
Prueba los casos límite y observa el flujo
Las pruebas deben cubrir tanto el camino feliz como las transiciones que suelen generar tickets. Incluye, como mínimo, aceptación antes y después del vencimiento, reenvío con enlace anterior, revocación, doble clic, invitación repetida, cuenta existente, sesión con otro correo y cambio de rol mientras la invitación está pendiente.
- Comprueba que un token usado, vencido o revocado no concede acceso.
- Verifica que un fallo de correo no cambia por error el estado de aceptación.
- Confirma que los reintentos no crean membresías o invitaciones duplicadas.
- Revisa que los mensajes expliquen el siguiente paso sin revelar datos de terceros.
En producción, observa cantidades de invitaciones pendientes, caducadas, revocadas y aceptadas, además de fallos de envío y tiempo hasta la aceptación. Interpreta esas señales juntas: muchas caducadas pueden apuntar a plazos poco adecuados o correos que no llegan; muchos reenvíos pueden indicar que el mensaje no es claro o que el flujo se atasca. La métrica por sí sola no demuestra la causa, así que acompáñala con soporte y pruebas de experiencia.
La regla de diseño que conecta todo el flujo es simple: cada invitación debe tener un destinatario, un estado, un plazo y una consecuencia inequívoca. Cuando esas decisiones están documentadas, el equipo puede resolver excepciones sin confundir invitaciones con cuentas, membresías o permisos generales.