Microsoft 365 и n8n: Outlook, Teams, SharePoint и сложности регистрации приложения в Azure

Тот, кто хочет подключить Microsoft 365 к n8n, чтобы обрабатывать письма из Outlook, автоматизировать сообщения в Teams или синхронизировать файлы в SharePoint, редко сталкивается с ограничением на уровне самого node. Node Outlook, Teams и SharePoint в n8n функционально хорошо оснащены и покрывают типичные сценарии использования. Настоящее препятствие почти всегда находится на уровень глубже: в регистрации приложения в Azure и настройке OAuth2, через которую n8n вообще получает доступ к учетной записи Microsoft 365. Тот, кто один раз аккуратно проходит этот шаг, закладывает основу сразу для всех трех сервисов, ведь Outlook, Teams и SharePoint технически работают в n8n через одно и то же подключение Microsoft Graph. Актуально на: июль 2026 года.

В этой статье показано, какие операции предлагают три самых важных node Microsoft 365, как пошагово выполняется регистрация приложения в Azure и на каком этапе большинство настроек застревают на практике.

Какие node Microsoft 365 предлагает n8n?

Узел Microsoft Outlook Node покрывает шесть ресурсов: календарь, контакты, черновики, встречи, папки, а также сообщения, включая вложения. Для сообщений, помимо обычных операций, таких как отправка, перемещение или ответ, также доступна функция "Send and Wait for Response", благодаря которой workflow приостанавливается, пока кто-то не даст согласие по почте или не предоставит обратную связь, например в виде свободного текста или через специально созданную форму.

Узел Microsoft Teams Node предоставляет операции для каналов, сообщений каналов, сообщений чата и задач, включая также "Send and Wait for Response" для сообщений чата. С его помощью можно, например, строить workflow согласования, в которых цифровой сотрудник отправляет сообщение в канал Teams и ждет ответа с кнопками, прежде чем workflow продолжится.

Узел Microsoft SharePoint Node устроен более компактно и покрывает файлы, элементы списков и списки: скачивание, обновление или загрузку файлов, создание, чтение, обновление, удаление или объединение элементов списка через upsert, а также получение одного или нескольких списков.

Все три node могут работать либо с привязанными к пользователю учетными данными OAuth2, либо, начиная с версии 2, с субъектом службы Microsoft Entra, то есть с доступом только для приложения без вошедшего пользователя. Для клиентов Government Cloud в учетных данных дополнительно нужно выбрать соответствующий базовый URL API Microsoft Graph.

Регистрация приложения в Azure шаг за шагом

Прежде чем заработает любой из трех node, n8n нужно зарегистрированное приложение в Azure, точнее в Центре администрирования Microsoft Entra. Согласно документации n8n об учетных данных Microsoft это происходит следующим образом:

• В портале регистрации приложений Microsoft выбрать "Register an application" и задать имя приложения.
• В разделе "Supported account types" выбрать вариант "Accounts in any organizational directory ... and personal Microsoft accounts", чтобы вход через OAuth2 работал в n8n.
• В разделе "Web" в качестве платформы скопировать URL обратного вызова OAuth из учетных данных n8n и указать его как URI перенаправления.
• После регистрации скопировать Application (client) ID и вставить его в n8n как Client ID.
• В разделе "Certificates & secrets" создать новый Client Secret, скопировать значение и указать его в n8n как Client Secret.
• В n8n нажать "Connect my account" и войти с учетной записью Microsoft 365.

Стоит знать одну деталь из документации Microsoft Learn о регистрации приложений: уже зарегистрированное приложение впоследствии нельзя перенести в другой клиент (tenant). Если кто-то работает в рамках клиентского проекта и случайно регистрирует приложение в собственном клиенте вместо клиента заказчика, регистрацию приходится создавать полностью заново. Поэтому перед первым нажатием на "New registration" стоит кратко проверить, в каком клиенте выполнен вход в данный момент.

При выборе типа учетной записи рекомендации n8n и Microsoft Learn немного расходятся: n8n для собственного подключения OAuth2 рекомендует самый широкий вариант с личными учетными записями, тогда как Microsoft Learn для большинства приложений советует "Single tenant only", то есть ограничение собственным клиентом. Для чисто внутренней автоматизации компании, где доступ должны получать только сотрудники собственной организации, более узкий вариант с одним клиентом обычно является более чистым выбором, даже если n8n по соображениям совместимости показывает открытый вариант в качестве стандартного примера.

Самое частое препятствие: согласие администратора для корпоративных учетных записей

Безусловно, самое частое сообщение об ошибке при первой попытке подключения касается не самой регистрации приложения, а согласования запрошенных разрешений. Как только учетная запись Microsoft 365 начинает управляться ИТ-отделом компании через Microsoft Entra, согласия отдельного пользователя часто оказывается недостаточно. Согласно документации n8n, для клиента должна быть включена настройка "User can consent to apps accessing company data on their behalf", либо администратор предоставляет согласие отдельно.

На практике, согласно Microsoft Learn, это происходит так: после регистрации приложение сначала получает только базовое разрешение User.Read. Для всех остальных разрешений (scopes), например Mail.ReadWrite или Calendars.ReadWrite, администратор заходит в регистрацию приложения в раздел "API permissions", нажимает "Grant admin consent" и подтверждает согласие для всего клиента. Только после этого статус соответствующего разрешения показывает "Granted". Тот, кто пропускает этот шаг, часто получает при "Connect my account" в n8n сообщение об ошибке о том, что администратор должен дать согласие, хотя Client ID, Client Secret и URI перенаправления указаны верно. На практике это означает: прежде чем тестировать интеграцию M365 у заказчика, стоит коротко позвонить в его ИТ-отдел, чтобы для новой регистрации приложения было предоставлено согласие администратора.

Особенности отдельных сервисов

Outlook

Для доступа к общему почтовому ящику конфигурация учетных данных Outlook в n8n предлагает опцию "Use Shared Inbox" с дополнительным полем для User Principal Name или ID почтового ящика. Для общего варианта учетных данных Microsoft OAuth2 n8n указывает в качестве типичных разрешений (scopes) Mail.ReadWrite, Mail.Send, Calendars.ReadWrite и Contacts.ReadWrite.

SharePoint

Для SharePoint в учетных данных дополнительно требуется поле поддомена, например "tenant123" из URL tenant123.sharepoint.com. В отношении разрешений n8n различает Application Permissions, такие как Sites.Read.All и Sites.ReadWrite.All, и Delegated Permissions, такие как SearchConfiguration.Read.All и SearchConfiguration.ReadWrite.All. Если предоставлена не та категория разрешений, node обычно сообщает об ошибке 403, хотя сама регистрация приложения выглядит корректной.

Teams

Для чисто автоматизаций между приложениями без вошедшего пользователя, например когда workflow постоянно публикует сообщения канала в фоновом режиме, начиная с версии 2 node доступна аутентификация через субъект службы Microsoft Entra. Она обходится без интерактивного входа и особенно подходит для сценариев взаимодействия сервер-сервер.

Client Secret или сертификат: какой вариант подходит

n8n поддерживает два способа аутентификации учетных данных Microsoft OAuth2 в Azure. Client Secret это более простой путь: текстовое значение создается в разделе "Certificates & secrets" и истекает через заданное время, поэтому его рано или поздно нужно обновлять. Вариант с сертификатом более трудоемкий, но более долговечный. Согласно документации n8n, подходящий сертификат можно создать с помощью OpenSSL:

```

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

```

Важно здесь: это должен быть ключ RSA. Частая ошибка это использование ключей EC или Ed25519, которые Azure не принимает для этой цели. После создания в регистрацию приложения в разделе "Certificates" загружается только публичный файл сертификата, тогда как приватный ключ и сертификат вводятся в n8n. Для большинства небольших и средних настроек вполне достаточно Client Secret с напоминанием в календаре о своевременном обновлении.

Когда эта основа заложена, на ней можно строить дальше с помощью автоматизаций n8n от NordFlux, например, чтобы строить workflow согласования через Outlook или Teams, в которых цифровые сотрудники подготавливают задачи, а людям остается только принять решение одним кликом. При этом вы сохраняете контроль над каждым шагом, потому что каждое разрешение остается видимым по отдельности и его можно отозвать в любой момент.

Часто задаваемые вопросы

Почему n8n не подключается к моей учетной записи Microsoft 365, хотя Client ID и Secret верны?

В большинстве случаев отсутствует согласие администратора на запрошенные разрешения. Если учетная запись управляется ИТ-отделом компании через Microsoft Entra, должна быть включена настройка клиента для согласия пользователя, либо администратор должен явно предоставить согласие администратора в разделе "API permissions" в регистрации приложения.

Достаточно ли одной регистрации приложения одновременно для Outlook, Teams и SharePoint?

Да, технически одной регистрации приложения достаточно для всех трех сервисов, поскольку они работают через одно и то же подключение Microsoft Graph. На практике все же стоит осознанно добавлять нужные разрешения (scopes) для каждого сервиса, например разрешения для почты для Outlook и разрешения для сайтов для SharePoint, вместо того чтобы сразу запрашивать все доступные разрешения.

Что делать, если я случайно зарегистрировал приложение не в том клиенте?

Согласно Microsoft Learn, уже зарегистрированное приложение нельзя перенести в другой клиент. В этом случае остается только заново создать регистрацию приложения в правильном клиенте, а затем удалить старую, неверно размещенную регистрацию.

Client Secret или сертификат, что лучше выбрать для n8n?

Для большинства настроек достаточно Client Secret, он быстрее настраивается, но истекает через заданное время и требует обновления. Сертификат с ключом RSA сложнее в настройке, но подходит, если учетные данные должны оставаться действительными как можно дольше без ручного вмешательства.

Нужны ли для SharePoint другие разрешения, чем для Outlook?

Да. Для Outlook обычно достаточно делегированных разрешений (scopes) для почты и календаря, таких как Mail.ReadWrite или Calendars.ReadWrite. Для SharePoint дополнительно нужны Application Permissions, такие как Sites.Read.All или Sites.ReadWrite.All, а также частично делегированные разрешения для конфигурации поиска, в зависимости от того, какие операции должен выполнять node.