Arquitectura de referencia
Del visitante a Teams, al flujo y de vuelta con control
En el patrón documentado, un mensaje del widget o canal social llega al canal Teams elegido. En la pestaña Power Platform se define una palabra clave por canal. Power Automate escucha con el trigger de palabras clave de Teams y después evalúa condiciones, lee datos autorizados o publica una tarjeta.
La vuelta es la prueba decisiva. Consultar el CRM no responde por sí solo al visitante. El piloto debe distinguir una publicación interna de Teams de un mensaje @WebChat que vuelve al cliente y demostrar cuándo se desactiva la automatización para que intervenga una persona.
| Componente | Papel documentado | Validar antes de producción |
|---|---|---|
| Canal WebChat | Entrada en Teams y palabra clave por canal | Origen, destino y respuesta interna o externa |
| Conector Teams | Triggers y acciones para mensajes o tarjetas | Equipo, canal, propietario, permisos y límites |
| Power Automate | Condiciones, consultas, recordatorios y relevo | Entorno, errores, reintentos, monitorización y licencia |
| CRM/ERP/helpdesk | Leer datos actuales o ejecutar una acción | Conector/API, roles, minimización y escritura |
| AI/Adaptive Card | Sugerencia, contexto estructurado o acción | Fuentes, aprobación, inyección, permisos y fallback |
Licencia e identidad
Premium depende del flujo real
La guía de WebChat indica conectores premium para el patrón AI y recomienda una identidad Microsoft dedicada y reconocible para la conexión Teams. Microsoft distingue flujos automatizados, programados e instantáneos, además de contextos de usuario y Process. No es correcto afirmar sin diseño que basta un usuario Premium o que todos los agentes lo necesitan.
Registra owner, conexiones, usuarios run-only, service principals, entornos dev/test/prod, conectores premium o personalizados y ejecuciones previstas. Solicita una evaluación escrita. La licencia por canal de WebChat y el consumo Microsoft/Azure son bloques separados del coste total.
Gobierno
DLP es una barrera, no una aprobación de cumplimiento
- Clasificar conectores y endpoints personalizados en una política de datos aprobada.
- Separar desarrollo, prueba y producción y mover referencias y variables de forma controlada.
- Conceder al flujo y a los sistemas solo los permisos mínimos de lectura y escritura.
- Registrar triggers, consultas, tarjetas, respuestas, relevos y errores sin guardar chat innecesario.
- Definir timeout, reintento, alerta y operación manual si falla el flujo o un conector.
- Revisar conservación y borrado por separado en Teams, Power Platform, destino, AI y WebChat.
Aceptación
Ocho pruebas antes de aprobar producción
- 01
Cerrar alcance
Elegir un canal, trigger, sistema, consulta de solo lectura y relevo.
- 02
Documentar identidades
Fijar owner, conexión Teams, cuenta destino, administradores, secretos y sustitución.
- 03
Probar el camino correcto
Enviar mensaje, consultar el dato, revisar tarjeta y confirmar respuesta al visitante.
- 04
Negar accesos
Registros no autorizados, IDs manipulados y consultas amplias deben fallar de forma segura.
- 05
Forzar el relevo
Desactivar el bot, responder como agente y reactivarlo sin duplicados.
- 06
Simular fallos
Bloquear conector, destino y AI; comprobar alerta, retry y respuesta manual.
- 07
Probar concurrencia
Mensajes rápidos no deben duplicar acciones, tarjetas ni respuestas.
- 08
Aprobar coste y operación
Confirmar licencias, Azure, límites, monitorización, soporte y rollback.