n8n ile Microsoft 365: Outlook, Teams, SharePoint ve Azure Uygulama Kaydı Engelleri

Outlook'tan gelen e-postaları işlemek, Teams'te mesajları otomatikleştirmek veya SharePoint'te dosyaları senkronize etmek için Microsoft 365'i n8n'e bağlamak isteyen kişi, nadiren asıl node'da bir sınırla karşılaşır. n8n'deki Outlook, Teams ve SharePoint node'ları işlevsel olarak iyi donanımlıdır ve yaygın kullanım senaryolarını kapsar. Asıl engel neredeyse her zaman bir seviye daha derinde yer alır: n8n'in bir Microsoft 365 hesabına erişim elde etmesini sağlayan Azure uygulama kaydı ve OAuth2 kurulumunda. Bu adımı bir kez düzgün şekilde tamamlayan kişi, üç hizmet için de aynı anda temeli atmış olur, çünkü Outlook, Teams ve SharePoint n8n'de teknik olarak aynı Microsoft Graph bağlantısı üzerinden çalışır. Güncelleme tarihi: Temmuz 2026.

Bu yazı, üç önemli Microsoft 365 node'unun hangi işlemleri sunduğunu, Azure uygulama kaydının adım adım nasıl çalıştığını ve çoğu kurulumun pratikte nerede takıldığını gösteriyor.

n8n hangi Microsoft 365 node'larını sunuyor?

Microsoft Outlook Node altı kaynağı kapsar: takvim, kişiler, taslaklar, randevular, klasörler ve ekler dahil mesajlar. Mesajlarda, gönderme, taşıma veya yanıtlama gibi alışılmış işlemlerin yanı sıra "Send and Wait for Response" da kullanılabilir; bu, birisi e-posta yoluyla onay verene veya serbest metin ya da özel olarak oluşturulmuş bir form aracılığıyla geri bildirim sağlayana kadar bir workflow'u duraklatır.

Microsoft Teams Node kanallar, kanal mesajları, sohbet mesajları ve görevler için işlemler sunar; sohbet mesajları için de "Send and Wait for Response" dahildir. Bununla örneğin, dijital bir çalışanın bir Teams kanalına mesaj gönderdiği ve workflow'un devam etmesinden önce düğmeli bir yanıt beklediği onay workflow'ları oluşturulabilir.

Microsoft SharePoint Node daha sade yapılandırılmıştır ve dosyaları, liste öğelerini ve listeleri kapsar: dosya indirme, güncelleme veya yükleme, liste öğeleri oluşturma, okuma, güncelleme, silme veya upsert ile birleştirme, ayrıca tek veya birden çok listeyi alma.

Üç node da isteğe bağlı olarak ya kullanıcıya bağlı OAuth2 kimlik bilgileriyle ya da sürüm 2'den itibaren bir Microsoft Entra hizmet asıl kimliği (service principal) ile, yani oturum açmış bir kullanıcı olmadan yalnızca uygulama erişimiyle çalışabilir. Government Cloud kiracıları için kimlik bilgilerinde ayrıca uygun Microsoft Graph API temel URL'sinin seçilmesi gerekir.

Azure Uygulama Kaydı Adım Adım

Üç node'dan biri çalışmadan önce, n8n'in Azure'da, daha doğrusu Microsoft Entra Yönetim Merkezi'nde kayıtlı bir uygulamaya ihtiyacı vardır. n8n'in Microsoft kimlik bilgileri belgelerine göre bu şu şekilde işler:

• Microsoft Application Registration Portal üzerinde "Register an application" seçilip uygulamaya bir isim verilir.
• "Supported account types" altında, n8n'de OAuth2 girişinin çalışması için "Accounts in any organizational directory ... and personal Microsoft accounts" seçeneği seçilir.
• Platform olarak "Web" altında, n8n kimlik bilgisi kaydından OAuth geri çağırma URL'si kopyalanır ve yönlendirme URI'si olarak girilir.
• Kayıttan sonra Application (client) ID kopyalanır ve n8n'de Client ID olarak eklenir.
• "Certificates & secrets" altında yeni bir Client Secret oluşturulur, değer kopyalanır ve n8n'de Client Secret olarak girilir.
• n8n'de "Connect my account" tıklanır ve Microsoft 365 hesabıyla oturum açılır.

Şurada bilinmesi faydalı bir ayrıntı var: Microsoft Learn uygulama kaydı belgeleri bir kez kaydedilmiş bir uygulamanın sonradan başka bir kiracıya (tenant) taşınamayacağını belirtir. Bir müşteri projesi kapsamında çalışan ve uygulamayı yanlışlıkla müşteri kiracısı yerine kendi kiracısında kaydeden kişi, kaydı tamamen yeniden oluşturmak zorunda kalır. Bu yüzden ilk kez "New registration" tıklamadan önce hangi kiracıda oturum açık olunduğunu kısaca kontrol etmekte fayda vardır.

Hesap türü seçiminde n8n ve Microsoft Learn tavsiyelerinde biraz farklılaşır: n8n kendi OAuth2 bağlantısı için kişisel hesapları da içeren en geniş seçeneği önerirken, Microsoft Learn çoğu uygulama için "Single tenant only", yani kendi kiracısıyla sınırlama tavsiye eder. Yalnızca kendi kuruluşunun çalışanlarının erişim kazanması gereken, tamamen şirket içi bir otomasyon için, n8n uyumluluk nedeniyle açık varyantı standart örnek olarak gösterse de, daha dar olan tek kiracı seçeneği genellikle daha temiz bir tercihtir.

En Sık Karşılaşılan Engel: Kurumsal Hesaplarda Yönetici Onayı

İlk bağlantı denemesinde açık ara en sık görülen hata mesajı, uygulama kaydının kendisiyle değil, talep edilen izinlerin onaylanmasıyla ilgilidir. Bir Microsoft 365 hesabı bir şirket BT departmanı tarafından Microsoft Entra üzerinden yönetildiği anda, tek bir kullanıcının onayı çoğu zaman yeterli olmaz. n8n belgelerine göre, ya kiracı için "User can consent to apps accessing company data on their behalf" ayarının etkinleştirilmiş olması ya da bir yöneticinin onayı ayrıca vermesi gerekir.

Pratikte, Microsoft Learn'e göre bu şu şekilde işler: kayıttan sonra uygulama önce yalnızca temel izin olan User.Read'i alır. Mail.ReadWrite veya Calendars.ReadWrite gibi diğer tüm izinler (scope'lar) için bir yönetici, uygulama kaydında "API permissions" altında "Grant admin consent"e tıklar ve onayı tüm kiracı için doğrular. Ancak bundan sonra ilgili iznin durumu "Granted" olarak görünür. Bu adımı atlayan kişi, n8n'de "Connect my account" sırasında, Client ID, Client Secret ve yönlendirme URI'si doğru girilmiş olsa bile, yöneticinin onay vermesi gerektiğine dair bir hata mesajı alır. Pratikte bu şu anlama gelir: bir müşteride M365 entegrasyonu test edilmeden önce, yeni uygulama kaydı için yönetici onayının verilmesi amacıyla müşterinin BT departmanını kısa bir aramayla bilgilendirmekte fayda vardır.

Hizmete Özgü Ayrıntılar

Outlook

Paylaşılan bir posta kutusuna erişim için, n8n'deki Outlook kimlik bilgisi yapılandırması, posta kutusunun User Principal Name'i veya ID'si için ek bir alanla birlikte "Use Shared Inbox" seçeneğini sunar. Genel Microsoft OAuth2 kimlik bilgisi varyantı için n8n, tipik izinler (scope'lar) olarak Mail.ReadWrite, Mail.Send, Calendars.ReadWrite ve Contacts.ReadWrite'ı belirtir.

SharePoint

SharePoint, kimlik bilgilerinde ayrıca bir alt alan adı alanı gerektirir, örneğin tenant123.sharepoint.com URL'sindeki "tenant123" gibi. İzinler konusunda n8n, Sites.Read.All ve Sites.ReadWrite.All gibi Application Permissions ile SearchConfiguration.Read.All ve SearchConfiguration.ReadWrite.All gibi Delegated Permissions arasında ayrım yapar. Yanlış izin kategorisi verildiğinde, uygulama kaydı doğru görünse bile node genellikle bir 403 hatası bildirir.

Teams

Oturum açmış bir kullanıcı olmadan, tamamen uygulamadan uygulamaya otomasyonlar için, örneğin bir workflow'un arka planda sürekli olarak kanal mesajları yayınladığı durumlarda, node sürüm 2'den itibaren Microsoft Entra hizmet asıl kimliği kimlik doğrulaması sunulur. Bu, etkileşimli oturum açma gerektirmez ve özellikle sunucudan sunucuya senaryolar için uygundur.

Client Secret mi Sertifika mı: Hangi Varyant Uygun

n8n, Microsoft OAuth2 kimlik bilgilerinin Azure'a karşı kimlik doğrulaması için iki yol destekler. Client Secret daha basit olan yoldur: "Certificates & secrets" altında bir metin değeri oluşturulur ve belirlenen bir süre sonra geçerliliğini yitirir, dolayısıyla bir noktada yenilenmesi gerekir. Sertifika varyantı daha zahmetlidir, ancak daha uzun ömürlüdür. n8n belgelerine göre, uygun bir sertifika OpenSSL ile oluşturulabilir:

```

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

```

Burada önemli olan: bir RSA anahtarı olması gerekir. Sık yapılan bir hata, Azure'ın bu amaç için kabul etmediği EC veya Ed25519 anahtarlarının kullanılmasıdır. Oluşturmadan sonra, uygulama kaydında "Certificates" altına yalnızca genel sertifika dosyası yüklenirken, özel anahtar ve sertifika n8n'e girilir. Çoğu küçük ve orta ölçekli kurulum için, takvimde zamanında yenileme için bir hatırlatıcı ile birlikte bir Client Secret tamamen yeterlidir.

Bu temeller bir kez oturduktan sonra, üzerine NordFlux'un n8n otomasyonları ile inşa edilebilir; örneğin dijital çalışanların görevleri hazırladığı ve insanların yalnızca bir tık ile karar verdiği, Outlook veya Teams üzerinden onay workflow'ları oluşturmak için. Bu sırada her adım üzerindeki kontrolü elinde tutarsın, çünkü her izin ayrı ayrı görünür kalır ve istenildiği zaman geri alınabilir.

Sık Sorulan Sorular

Client ID ve Secret doğru olmasına rağmen n8n neden Microsoft 365 hesabıma bağlanmıyor?

Çoğu durumda, talep edilen izinler için bir yöneticinin onayı eksiktir. Hesap bir şirket BT departmanı tarafından Microsoft Entra üzerinden yönetiliyorsa, ya kullanıcı onayı için kiracı ayarının etkinleştirilmiş olması ya da bir yöneticinin uygulama kaydında "API permissions" altında yönetici onayını açıkça vermesi gerekir.

Outlook, Teams ve SharePoint için aynı anda tek bir uygulama kaydı yeterli mi?

Evet, teknik olarak aynı Microsoft Graph bağlantısı üzerinden çalıştıkları için üç hizmet için de tek bir uygulama kaydı yeterlidir. Pratikte yine de, başlangıçta tüm mevcut izinleri talep etmek yerine, örneğin Outlook için mail izinlerini ve SharePoint için site izinlerini olmak üzere, hizmet başına gerekli izinleri (scope'ları) bilinçli olarak eklemekte fayda vardır.

Uygulamayı yanlışlıkla yanlış kiracıda kaydettiysem ne yapmalıyım?

Microsoft Learn'e göre, zaten kayıtlı bir uygulama başka bir kiracıya taşınamaz. Bu durumda tek seçenek, uygulama kaydını doğru kiracıda yeniden oluşturmak ve ardından eski, yanlış yerleştirilmiş kaydı silmektir.

Client Secret mi sertifika mı, n8n için hangisi daha iyi bir seçim?

Çoğu kurulum için bir Client Secret yeterlidir, daha hızlı kurulur ancak belirlenen bir süre sonra geçerliliğini yitirir ve yenilenmesi gerekir. RSA anahtarlı bir sertifika kurulumu daha zahmetlidir, ancak kimlik bilgilerinin manuel müdahale olmadan mümkün olduğunca uzun süre geçerli kalması gerektiğinde uygundur.

SharePoint için Outlook'tan farklı izinlere ihtiyacım var mı?

Evet. Outlook için genellikle Mail.ReadWrite veya Calendars.ReadWrite gibi delege edilmiş mail ve takvim izinleri (scope'ları) yeterlidir. SharePoint ayrıca Sites.Read.All veya Sites.ReadWrite.All gibi Application Permissions ile node'un hangi işlemleri gerçekleştirmesi gerektiğine bağlı olarak kısmen delege edilmiş arama yapılandırması izinlerine ihtiyaç duyar.