Microsoft 365 con n8n: Outlook, Teams, SharePoint y los obstáculos del registro de aplicaciones de Azure

Quien quiera conectar Microsoft 365 con n8n, para procesar correos de Outlook, automatizar mensajes en Teams o sincronizar archivos en SharePoint, rara vez encuentra un límite en el propio node. Los nodes de Outlook, Teams y SharePoint en n8n están bien equipados funcionalmente y cubren los casos de uso habituales. El obstáculo real casi siempre se encuentra un nivel más abajo: en el registro de aplicaciones de Azure y en la configuración OAuth2, mediante la cual n8n obtiene acceso a una cuenta de Microsoft 365 en primer lugar. Quien complete este paso correctamente una vez ha sentado la base para los tres servicios al mismo tiempo, ya que Outlook, Teams y SharePoint funcionan técnicamente en n8n a través de la misma conexión de Microsoft Graph. Actualizado: julio de 2026.

Este artículo muestra qué operaciones ofrecen los tres nodes de Microsoft 365 más importantes, cómo funciona el registro de aplicaciones de Azure paso a paso y en qué punto se atascan la mayoría de las configuraciones en la práctica.

¿Qué nodes de Microsoft 365 ofrece n8n?

El Microsoft Outlook Node cubre seis recursos: calendario, contactos, borradores, citas, carpetas y mensajes, incluidos los archivos adjuntos. En los mensajes, además de las operaciones habituales como enviar, mover o responder, también está disponible "Send and Wait for Response", con la que un workflow se pausa hasta que alguien concede una aprobación por correo o da una respuesta, por ejemplo como texto libre o mediante un formulario creado a medida.

El Microsoft Teams Node aporta operaciones para canales, mensajes de canal, mensajes de chat y tareas, incluyendo también "Send and Wait for Response" para mensajes de chat. Con esto se pueden construir, por ejemplo, workflows de aprobación en los que un trabajador digital envía un mensaje a un canal de Teams y espera una respuesta con botones antes de que el workflow continúe.

El Microsoft SharePoint Node está estructurado de forma más ligera y cubre archivos, elementos de lista y listas: descargar, actualizar o subir archivos, crear, leer, actualizar, eliminar o combinar elementos de lista mediante upsert, así como obtener una o varias listas.

Los tres nodes pueden funcionar con credenciales OAuth2 vinculadas al usuario o, a partir de la versión 2, con un principal de servicio de Microsoft Entra, es decir, un acceso solo de aplicación sin usuario conectado. Para los inquilinos de Government Cloud también debe seleccionarse la URL base de la API de Microsoft Graph adecuada en las credenciales.

Registro de aplicaciones de Azure paso a paso

Antes de que funcione cualquiera de los tres nodes, n8n necesita una aplicación registrada en Azure, o más concretamente en el centro de administración de Microsoft Entra. Según la documentación de n8n sobre credenciales de Microsoft esto funciona así:

• En el Portal de registro de aplicaciones de Microsoft elegir "Register an application" y asignar un nombre a la aplicación.
• En "Supported account types" elegir la opción "Accounts in any organizational directory ... and personal Microsoft accounts" para que el inicio de sesión OAuth2 funcione en n8n.
• En "Web" como plataforma, copiar la URL de retorno de OAuth desde el conjunto de credenciales de n8n e introducirla como URI de redirección.
• Tras el registro, copiar el Application (client) ID e introducirlo en n8n como Client ID.
• En "Certificates & secrets" crear un nuevo Client Secret, copiar el valor e introducirlo en n8n como Client Secret.
• En n8n, hacer clic en "Connect my account" e iniciar sesión con la cuenta de Microsoft 365.

Vale la pena conocer un detalle de la documentación de Microsoft Learn sobre el registro de aplicaciones: una aplicación ya registrada no se puede trasladar posteriormente a otro inquilino. Quien trabaje en el marco de un proyecto de cliente y registre la aplicación accidentalmente en su propio inquilino en lugar de en el del cliente debe crear el registro completamente de nuevo. Por eso vale la pena comprobar brevemente en qué inquilino se está conectado antes del primer clic en "New registration".

En la elección del tipo de cuenta, n8n y Microsoft Learn difieren ligeramente en su recomendación: n8n recomienda la opción más amplia con cuentas personales para su propia conexión OAuth2, mientras que Microsoft Learn aconseja "Single tenant only" para la mayoría de las aplicaciones, es decir, una restricción al propio inquilino. Para una automatización puramente interna de la empresa, en la que solo deben tener acceso los empleados de la propia organización, la opción de inquilino único más restrictiva suele ser la elección más limpia, aunque n8n muestre la variante abierta como ejemplo estándar por motivos de compatibilidad.

El obstáculo más frecuente: el consentimiento del administrador en cuentas empresariales

Con diferencia, el mensaje de error más frecuente en el primer intento de conexión no se refiere al registro de la aplicación en sí, sino a la aprobación de los permisos solicitados. En cuanto una cuenta de Microsoft 365 es gestionada por el departamento de TI de una empresa a través de Microsoft Entra, el consentimiento del usuario individual a menudo no es suficiente. Según la documentación de n8n, o bien debe estar activada para el inquilino la configuración "User can consent to apps accessing company data on their behalf", o bien un administrador debe conceder el consentimiento por separado.

En la práctica, según Microsoft Learn, esto funciona así: tras el registro, la aplicación recibe inicialmente solo el permiso básico User.Read. Para todos los demás permisos (scopes), por ejemplo Mail.ReadWrite o Calendars.ReadWrite, un administrador accede al registro de la aplicación en "API permissions", pulsa "Grant admin consent" y confirma el consentimiento para todo el inquilino. Solo entonces el estado del permiso correspondiente muestra "Granted". Quien se salte este paso suele recibir, al hacer "Connect my account" en n8n, un mensaje de error indicando que el administrador debe dar su consentimiento, aunque el Client ID, el Client Secret y la URI de redirección estén introducidos correctamente. En la práctica, esto significa: antes de probar una integración de M365 en un cliente, vale la pena hacer una breve llamada a su departamento de TI para que se conceda el consentimiento del administrador para el nuevo registro de aplicación.

Particularidades específicas de cada servicio

Outlook

Para el acceso a un buzón compartido, la configuración de credenciales de Outlook en n8n ofrece la opción "Use Shared Inbox" con un campo adicional para el User Principal Name o el ID del buzón. Para la variante genérica de credenciales de Microsoft OAuth2, n8n indica como permisos (scopes) típicos Mail.ReadWrite, Mail.Send, Calendars.ReadWrite y Contacts.ReadWrite.

SharePoint

SharePoint necesita además en las credenciales un campo de subdominio, por ejemplo "tenant123" de la URL tenant123.sharepoint.com. En cuanto a los permisos, n8n distingue entre Application Permissions como Sites.Read.All y Sites.ReadWrite.All, y Delegated Permissions como SearchConfiguration.Read.All y SearchConfiguration.ReadWrite.All. Si solo se concede la categoría incorrecta de permisos, el node suele devolver un error 403, aunque el registro de la aplicación en sí parezca correcto.

Teams

Para automatizaciones puramente de aplicación a aplicación sin usuario conectado, por ejemplo cuando un workflow publica de forma permanente mensajes de canal en segundo plano, la autenticación mediante principal de servicio de Microsoft Entra está disponible a partir de la versión 2 del node. Funciona sin inicio de sesión interactivo y es especialmente adecuada para escenarios de servidor a servidor.

Client Secret o certificado: qué variante encaja

n8n admite dos formas para que las credenciales de Microsoft OAuth2 se autentiquen frente a Azure. El Client Secret es la vía más sencilla: se genera un valor de texto en "Certificates & secrets" y caduca después de un tiempo determinado, por lo que en algún momento hay que renovarlo. La variante de certificado es más laboriosa, pero más duradera. Según la documentación de n8n, se puede generar un certificado adecuado con OpenSSL:

```

openssl req -x509 -newkey rsa:2048 -nodes -keyout private-key.pem -out certificate.pem -days 365 -subj "/CN=n8n-microsoft-cert"

```

Importante aquí: debe ser una clave RSA. Un error frecuente es el uso de claves EC o Ed25519, que Azure no acepta para este fin. Tras la generación, solo se sube el archivo de certificado público en "Certificates" dentro del registro de la aplicación, mientras que la clave privada y el certificado se introducen en n8n. Para la mayoría de las configuraciones pequeñas y medianas, un Client Secret con un recordatorio en el calendario para la renovación a tiempo es totalmente suficiente.

Una vez sentadas estas bases, se puede construir sobre las automatizaciones de n8n de NordFlux, por ejemplo para crear workflows de aprobación a través de Outlook o Teams, en los que los trabajadores digitales preparan las tareas y las personas solo tienen que tomar la decisión con un clic. Así mantienes el control sobre cada paso, porque cada permiso permanece visible individualmente y se puede revocar en cualquier momento.

Preguntas frecuentes

¿Por qué n8n no se conecta a mi cuenta de Microsoft 365 aunque el Client ID y el Secret sean correctos?

En la mayoría de los casos falta el consentimiento de un administrador a los permisos solicitados. Si la cuenta está gestionada por el departamento de TI de una empresa a través de Microsoft Entra, debe estar activada la configuración del inquilino para el consentimiento del usuario, o un administrador debe conceder explícitamente el consentimiento del administrador en "API permissions" dentro del registro de la aplicación.

¿Es suficiente un único registro de aplicación para Outlook, Teams y SharePoint al mismo tiempo?

Sí, técnicamente un único registro de aplicación es suficiente para los tres servicios, ya que funcionan a través de la misma conexión de Microsoft Graph. En la práctica, aun así vale la pena añadir deliberadamente los permisos (scopes) necesarios por servicio, por ejemplo permisos de correo para Outlook y permisos de sitios para SharePoint, en lugar de solicitar desde el principio todos los permisos disponibles.

¿Qué hago si he registrado la aplicación accidentalmente en el inquilino equivocado?

Según Microsoft Learn, una aplicación ya registrada no se puede trasladar a otro inquilino. En este caso, la única opción es crear de nuevo el registro de la aplicación en el inquilino correcto y después eliminar el registro antiguo, mal ubicado.

Client Secret o certificado, ¿cuál es la mejor opción para n8n?

Para la mayoría de las configuraciones basta con un Client Secret, se configura más rápido, pero caduca tras un tiempo determinado y hay que renovarlo. Un certificado con clave RSA es más laborioso de configurar, pero resulta útil si las credenciales deben permanecer válidas el mayor tiempo posible sin intervención manual.

¿Necesito permisos diferentes para SharePoint que para Outlook?

Sí. Para Outlook suelen bastar los permisos (scopes) delegados de correo y calendario como Mail.ReadWrite o Calendars.ReadWrite. SharePoint necesita además Application Permissions como Sites.Read.All o Sites.ReadWrite.All, así como en parte permisos delegados para la configuración de búsqueda, según las operaciones que deba ejecutar el node.