Volver a todas las integraciones
Calendar & email

Microsoft 365 y Outlook Calendar

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.

En esta página
Qué conectaCómo conectarloQué datos se muevenEjemplo prácticoLímites y trampas comunes
¿Necesitas que lo conectemos?

Trae tus herramientas a una llamada: lo conectamos, probamos cada campo en ambas direcciones y te lo entregamos documentado.

Agenda una llamada
01

Qué conecta

Del 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.

02

Cómo conectarlo

  1. Define qué cuenta de Microsoft va a conectar cada usuario y si es una cuenta profesional o educativa en un tenant administrado o una cuenta personal de Outlook. Las dos se comportan distinto y los caminos para resolver problemas se separan de inmediato.
  2. En un tenant administrado, habla con el administrador antes de que lo intente el primer usuario. Pregunta si se permite que los usuarios den consentimiento a aplicaciones de terceros, si existe un flujo de consentimiento del administrador y si hay políticas de acceso condicional que restrinjan el inicio de sesión por ubicación, cumplimiento del dispositivo o estado de la autenticación multifactor.
  3. Confirma que el buzón es un buzón real con licencia y no un buzón compartido o una lista de distribución. Por lo general, los buzones compartidos no pueden completar por sí solos una autorización delegada por un usuario; en su lugar se conecta un usuario con licencia que tenga acceso delegado.
  4. Revisa la zona horaria y el horario laboral del usuario tanto en Outlook como en su perfil de usuario de AppBO, y haz que coincidan antes de probar cualquier cosa.
  5. En la subcuenta, abre la sección de integraciones o de configuración del calendario e inicia la conexión con Microsoft. Si la plataforma ofrece conexiones separadas de calendario y de email para Microsoft, decide cuáles necesitas; conectar el calendario no te da automáticamente la capacidad de enviar.
  6. Completa el inicio de sesión de Microsoft y la pantalla de consentimiento como ese usuario. Lee los permisos que aparecen en la propia pantalla de consentimiento. Esa es la lista oficial para la versión de la aplicación que estás autorizando, y los nombres de los permisos de Graph cambian con el tiempo.
  7. Si el consentimiento está bloqueado, anota el identificador exacto del error que devuelve Microsoft y pásaselo al administrador. El consentimiento del administrador se otorga en la sección de aplicaciones empresariales del tenant; la plataforma no puede otorgarlo por él.
  8. Elige qué calendarios de Outlook se leen para revisar choques, incluido cualquier calendario secundario que la persona de verdad use. Selecciona el único calendario donde la plataforma escribe las reservas.
  9. Configura el lado del envío si conectaste el buzón: el nombre del remitente, el comportamiento de la dirección de respuesta y si los mensajes enviados deben guardarse en la carpeta Elementos enviados del usuario.
  10. Decide cómo se manejan las respuestas. Leer las respuestas de vuelta en la conversación de la plataforma requiere permiso de lectura de correo; confirma que la pantalla de consentimiento lo otorgó y confirma con el usuario que está de acuerdo con eso.
  11. Configura el calendario de reservas como siempre (duración del horario, horario laboral, márgenes, anticipación mínima, límites) y asígnale el usuario conectado.
  12. Verifica la dirección de lectura creando un evento en Outlook encima de un horario ofrecido y confirmando que la página de reservas deja de ofrecerlo.
  13. Verifica la dirección de escritura reservando una cita de prueba y confirmando que aparece en Outlook con la hora, la zona horaria y la lista de asistentes correctas.
  14. Verifica el envío mandando un email desde la plataforma a un contacto de prueba y después revisa que el mensaje llegó, que la dirección del remitente es la de Microsoft, que aparece en Elementos enviados si así lo configuraste y que los encabezados muestran que se autenticó como se esperaba.
  15. Verifica la recepción de respuestas contestando el mensaje de prueba desde el buzón del contacto y confirmando que la respuesta aparece en la conversación de la plataforma, en el mismo hilo que el original.
  16. Registra la cuenta conectada, la fecha y si hizo falta el consentimiento del administrador, y después borra los datos de prueba.
03

Qué datos se mueven

De la plataforma a Microsoft

  • Eventos de calendario de las citas reservadas mediante un calendario de reservas conectado, escritos en el único calendario de Outlook elegido.
  • Asunto, cuerpo, inicio y fin del evento con zona horaria, ubicación o enlace de la reunión, y el contacto como asistente cuando así está configurado.
  • Actualizaciones y cancelaciones de eventos cuando la cita se reagenda o se cancela en la plataforma.
  • Emails salientes, con asunto, cuerpo HTML, archivos adjuntos y cualquier dirección de respuesta personalizada.
  • Una copia de cada mensaje enviado en Elementos enviados, cuando esa opción está activada.
  • Encabezados de hilo en las respuestas que envía la plataforma, para que el mensaje caiga en la conversación existente de Outlook en lugar de iniciar una nueva.

De Microsoft a la plataforma

  • Intervalos de disponibilidad (libre/ocupado) de los calendarios seleccionados, que quitan horarios de las páginas de reservas.
  • Cambios hechos en Outlook a los eventos creados por la plataforma: hora movida, evento borrado, respuestas de los asistentes.
  • Respuestas entrantes a los mensajes enviados por la plataforma, relacionadas con el contacto y asociadas a la conversación.
  • Notificaciones de rebote y de fallas de entrega que llegan al buzón como mensajes.
  • La lista de buzones y calendarios, para que elijas qué leer y dónde escribir.

Lo que no se mueve

  • Eventos de calendario o correos históricos anteriores a la conexión. Nada se carga hacia atrás.
  • La bandeja de entrada completa. Solo se incorporan los mensajes que la plataforma puede asociar con sus propias conversaciones; el resto del correo se queda en Outlook.
  • Contactos y listas de distribución. La libreta de direcciones de Outlook no es una fuente del CRM y no crea contactos.
  • Chats de Teams, tareas de Planner, archivos de SharePoint y elementos de To Do. Nada de esto entra en el alcance.
  • Categorías, marcas, reglas y firmas de Outlook. Una firma configurada en Outlook no se aplica al correo enviado por la plataforma; configura la firma en la plataforma.
  • Los recordatorios de eventos propios de Outlook, que siguen siendo independientes de los recordatorios de la plataforma.
  • La disponibilidad de buzones compartidos y de salas, a menos que la cuenta conectada sea un usuario con licencia y acceso delegado y que la plataforma muestre ese calendario.
04

Ejemplo práctico

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.

  1. Una consultora conecta su cuenta profesional de Microsoft. El administrador del tenant ya otorgó el consentimiento del administrador para la aplicación, así que su inicio de sesión se completa sin bloqueos.
  2. Selecciona su calendario principal de Outlook y un calendario compartido de entregas para revisar choques, y su calendario principal como destino de escritura.
  3. Una oportunidad llega a la etapa de propuesta y un flujo de trabajo envía el email con la propuesta. La plataforma lo envía a través de su buzón, así que el cliente ve como remitente la dirección de la firma y una copia queda en su carpeta Elementos enviados.
  4. Dos días después, el cliente responde con una pregunta. Microsoft entrega la respuesta en su buzón; la plataforma la lee, relaciona al remitente con el contacto y la asocia a la conversación existente.
  5. Un flujo que se dispara con la respuesta entrante saca al contacto de la secuencia de seguimiento y crea una tarea para la consultora.
  6. Ella contesta desde la conversación de la plataforma. La respuesta lleva los encabezados de hilo del original, así que aparece en el hilo que el cliente ya tiene en lugar de como un mensaje nuevo, y otra vez queda en Elementos enviados.
  7. Su respuesta incluye el enlace de reserva para una llamada de seguimiento de treinta minutos.
  8. El cliente abre la página de reservas. La plataforma consulta la disponibilidad tanto de su calendario principal como del calendario compartido de entregas; un taller de entrega el martes por la tarde bloquea esos horarios.
  9. El cliente reserva el miércoles a las nueve. La plataforma crea la cita, se la asigna a la consultora y escribe un evento en Outlook con el nombre del cliente en el asunto, el enlace de la oportunidad en el cuerpo y el cliente como asistente.
  10. Outlook envía su invitación a la reunión; el cliente acepta y el estado de su respuesta aparece en el evento.
  11. La plataforma envía su propia confirmación con la marca del negocio y programa un recordatorio para la mañana de la llamada.
  12. El martes por la noche, la consultora mueve en Outlook la llamada del miércoles una hora más tarde. El cambio se sincroniza de vuelta, la hora de la cita se actualiza y el recordatorio se recalcula según el nuevo inicio.
  13. La llamada se hace. Ella marca el resultado de la cita en la plataforma, y un flujo avanza la oportunidad y programa el seguimiento para la decisión sobre la propuesta.
05

Límites y trampas comunes

Límites de uso

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.

Reintentos e idempotencia

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.

Trampas al mapear campos

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.

Creación de duplicados

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.

Pruebas contra producción

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.

Vencimiento de la autenticación

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.

Lo que se rompe con más frecuencia

  • El consentimiento del administrador nunca se otorgó, así que cada usuario ve un bloqueo que parece una falla de la plataforma.
  • Un acceso condicional que exige un dispositivo conforme, algo que las llamadas de la plataforma desde el servidor no pueden cumplir.
  • Un buzón compartido o de sala conectado directamente, que no puede completar el consentimiento delegado por un usuario.
  • Los límites de envío del buzón alcanzados por una campaña de marketing enviada desde el buzón de un usuario en lugar de un dominio de envío dedicado.
  • Reglas de Outlook que mueven el correo de la plataforma fuera de la carpeta que lee la plataforma, así que las respuestas nunca aparecen en la conversación.
  • La firma de Outlook, que la aplicación agrega en los envíos manuales pero que falta en los envíos de la plataforma, lo que da dos emails de aspecto distinto de la misma persona.
  • Una licencia que se le quita a un usuario que se va, lo que apaga tanto el calendario como el envío sin ningún aviso dentro de la plataforma.

Conéctalo con nosotros.

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