Cómo conectar una cuenta de trabajo de Microsoft para que AppBO lea la disponibilidad de Outlook, escriba las reservas y envíe desde el buzón de la empresa.
Trae tus herramientas a una llamada: lo conectamos, probamos cada campo en ambas direcciones y te lo entregamos documentado.
Agenda una llamadaDel lado de Microsoft hay una cuenta profesional o educativa de Microsoft 365, o una cuenta personal de Outlook. Detrás de ella hay un buzón de Exchange Online y un calendario, ambos accesibles mediante la API de Microsoft Graph: eventos de calendario con asistentes y estado de respuesta, información de disponibilidad (libre/ocupado), carpetas y mensajes de correo, y los identificadores de conversación que permiten que una respuesta quede en el mismo hilo que el mensaje al que contesta. Por encima de todo eso están las políticas a nivel del tenant, que es la diferencia que importa frente a una cuenta personal.
Del lado de AppBO están los mismos dos consumidores que en cualquier conexión de calendario y email: el calendario de reservas, que necesita saber cuándo alguien de verdad está ocupado, y el canal de email saliente, que necesita una dirección de remitente legítima y un lugar adonde lleguen las respuestas. Conectar Microsoft le da a un equipo que trabaja con Microsoft una sola fuente de verdad para su día y una sola dirección que sus clientes ya reconocen, sin pedirles que vivan en una segunda bandeja de entrada.
La razón práctica para elegir esto en lugar de un relay SMTP genérico es el manejo de hilos y la visibilidad. Como la plataforma habla con el buzón y no con un relay, un mensaje enviado puede aparecer en la carpeta Elementos enviados del propio usuario y una respuesta se puede leer de vuelta y asociar a la conversación del contacto. La razón práctica para tener cuidado es el tenant: el acceso condicional, las políticas de consentimiento de aplicaciones y las restricciones del buzón las define un administrador, así que una conexión que funciona para un usuario puede fallar para el siguiente por razones que no se ven desde la plataforma.
Escenario: una consultora que trabaja con Microsoft envía una propuesta desde el buzón de la firma, el cliente responde y se agenda una llamada de seguimiento en Outlook.
Microsoft Graph limita las solicitudes por aplicación, por usuario y por buzón, y Exchange Online aplica sus propios límites de envío por buzón en ventanas de tiempo móviles. Esos límites hacen que un buzón conectado no sirva para envíos masivos de marketing, sin importar cuánto te deje poner en cola la plataforma. Microsoft publica en su documentación las guías vigentes de limitación y los límites del servicio; revisa esas cifras antes de planear el volumen en lugar de descubrirlas a través de fallas. Cuando limita, Graph devuelve una indicación de cuándo volver a intentar, y una integración bien hecha espera en lugar de reintentar de inmediato.
Las limitaciones pasajeras y los tiempos de espera agotados se reintentan, y un reintento después de un tiempo agotado sin respuesta clara es de donde salen los duplicados: dos eventos para una reserva, o el mismo mensaje enviado dos veces. Si llamas a Graph por tu cuenta en lugar de usar la conexión nativa, usa tu propio identificador para cada operación lógica y revisa antes de crear. En los flujos de trabajo, ánclate a la cita o al evento de la respuesta entrante y protege la rama con una etiqueta, para que un disparador que se repite no vuelva a enviar.
En Graph las zonas horarias se expresan de forma explícita, y Outlook guarda la zona preferida del usuario por separado de la del evento; si no coincide con el perfil del usuario en la plataforma, los eventos quedan corridos una o varias horas, y los cambios de horario de verano son donde se nota. Verifica con una reserva real que cruce un cambio de horario si tu negocio pasa por uno. La dirección del remitente es el buzón, no lo que escribas en una plantilla, así que una plantilla con un remitente fijo va a ser reemplazada. La dirección de respuesta se comporta distinto si se envía desde el buzón de un usuario o mediante un relay, así que confirma a qué dirección llegan de verdad las respuestas.
Aparecen eventos duplicados cuando el calendario de destino también se lee para revisar choques, cuando dos calendarios de la plataforma escriben en el mismo calendario de Outlook o cuando el usuario tiene una regla de buzón que copia eventos. Aparecen contactos duplicados cuando una respuesta llega desde un alias de una dirección que ya está registrada; es común que los usuarios de Microsoft tengan varias direcciones proxy, así que normaliza y relaciona por todas las direcciones conocidas, no solo por la principal.
Un tenant de desarrollador de Microsoft es lo más parecido a un entorno de pruebas, y de verdad sirve para comprobar el flujo de consentimiento sin tocar las políticas de producción. No va a reproducir las reglas de acceso condicional del cliente, así que una conexión que funcionó en un tenant de desarrollador todavía puede fallar en el suyo. Prueba el camino de consentimiento en el tenant real con un usuario piloto antes de extenderlo a todos.
Los tokens de actualización se revocan con un cambio de contraseña, cuando un administrador revoca las sesiones, por una reevaluación del acceso condicional, al quitar la aplicación de las aplicaciones empresariales y cuando el propio usuario lo hace en los permisos de aplicaciones de su cuenta. Los cambios en la política de autenticación multifactor son una causa silenciosa frecuente. La falla es callada: se siguen ofreciendo reservas mientras se dejan de leer los choques, y el correo saliente se queda en cola o pasa a otro remitente. Vigila el estado de la conexión de cada usuario y trata la reconexión como mantenimiento de rutina.
Conectamos la integración, mapeamos los campos, probamos ambas direcciones y te la entregamos con los procedimientos (SOP) que tu equipo necesita para operarla.
Agenda una llamada