Belge otomasyonu: Google Workspace, n8n ve Cloudflare tarafında neler değişti?

Belge inceleme, onay, erişim kontrolü ve arka plan görevlerini bağlamak: 6 Ekim 2026 itibarıyla Google Workspace, n8n ve Cloudflare’dan altı güncelleme.

Talep otomasyonu çoğu zaman tanıdık bir noktada takılır: sistem veriyi toplamış, belgeyi hazırlamış, bildirim göndermiştir; ancak onay tekrar e-posta ve sohbete taşınır. Satış yöneticisi teklifi düzenler, mühendis gereksinimleri netleştirir, ekip lideri koşulları kontrol eder. İnsanlar farklı sürümleri tartışırken arka plan görevi başarısız olabilir, entegrasyon ihtiyacından fazla erişim alabilir.

Google Workspace, n8n ve Cloudflare’ın 30 Eylül ile 6 Ekim 2026 arasındaki duyuruları bu süreci yeniden incelemek için neden sunuyor. Birbiriyle bağlantılı üç ihtiyacı ele alıyorlar: belgelerde işbirliği, otomasyon izinlerini kontrol etme ve tarayıcı kapandıktan sonra çalışmayı sürdürme. Bu inceleme nelerin değiştiğine ve yeteneklerin tek akışa nasıl yerleştirilebileceğine bakıyor.

Değerlendirme tarihi 6 Ekim 2026. Aşağıdaki örnek, talep işlemek ve ticari teklif hazırlamak için önerilen mimaridir; test edilmiş ürün birleşimi değildir. Uygulamadan önce özellik kullanılabilirliği, uygulama izinleri ve belirli kurulumun davranışı kontrol edilmelidir.

Belge incelemesini iş akışına dahil etmek

Teknik gereksinimler ve eklerle talep alan üreticiyi düşünün. Fiyatlandırmadan önce mühendis teknik özellikleri netleştirmeli, satış yöneticisi teslim koşullarını doğrulamalı, ekip lideri istisnaları onaylamalıdır. Ortak belge bu kararları bağlar; ancak temel otomasyon yalnızca belgeyi oluşturup bağlantısını dağıtabilir.

Google’ın 30 Eylül duyurusu, Docs, Sheets ve Slides API’leriyle programatik yorum oluşturma, okuma ve yönetme desteğini anlatıyor. Google Docs önerilen düzenlemeleri de destekliyor: sistem bir metin değişikliğini insan incelemesine sunabilir. Sheets yorumları hücrelerle; Slides yorumları slaytlarla ve tekil sunum öğeleriyle ilişkili olabilir.

Bu örnekte yetenekler daha kesin incelemeyi destekleyebilir. Teslim tarihi eksikse otomasyon ilgili maddenin yanına soru koyabilir. Hesaplama teknik özelliklerde tutarsızlık bulursa düzeltme önerebilir. İnceleyen kişi sorunu bağlamında görür, tartışmalı bilginin bulunduğu yerde karar verir.

Ancak yorum API’leri onay kurallarını tanımlamaz. “Onaylandı” bütün teklif yerine tek maddeyi ifade edebilir. Mühendisin yanıtı ticari koşulların onayının yerini tutmaz. Bu yüzden görüşmeyle talep durumu arasındaki bağın kendi kuralları gerekir: kim karar verir, hangi sürümü inceler ve hangi işlem sonraki adıma izin verir?

Dağıtım 30 Eylül’de başladı ve 15 güne kadar sürebilir. 6 Ekim itibarıyla belirli hesapta kullanılabilirlik hâlâ kontrol edilmelidir. Google Docs, Sheets ve Slides MCP sunucularındaki yorum desteği geliştirici önizlemesindedir. Normal API üzerinden kullanılabilirlikle MCP entegrasyonunun hazırlığı ayrı değerlendirilmelidir.

Markdown devirleri basitleştirebilir

İkinci değişiklik belge biçimiyle ilgilidir. Google, Drive ve Docs’ta yerel Markdown desteğini duyurdu: kullanıcılar .md ve .markdown dosyalarını türünü değiştirmeden Docs’ta açabilir, düzenleyebilir ve birlikte çalışabilir. Drive, bağlantılar ve tablolar içeren işlenmiş önizlemeler kazanıyor.

Belge birkaç sistem arasında taşınıyorsa bu yardımcı olabilir. Gereksinimler Markdown’da saklanabilir, teklif taslağı hazırlamak için kullanılabilir, ardından bilinen ortak çalışma arayüzünde incelenebilir. Kaynak metin, inceleme belgesi ve sonraki adım için malzeme arasındaki manuel dönüştürmeleri azaltabilir.

İki Google duyurusu tek başına her yorum veya düzenleme önerisi API işleminin yerel Markdown dosyalarında aynı çalıştığını göstermez. Seçilen biçim; desteklenen işlemler, tablo ve bağlantıların korunması, yorum davranışı ve son sürümün alınması açısından test edilmelidir. Nihai belge PDF’ye dönüştürülecek veya müşteriye gönderilecekse bu özellikle önemlidir.

Markdown dağıtımı 5 Ekim’de başladı ve o da 15 güne kadar sürebilir. Bu nedenle uygulama planı, özelliğin henüz görünmediği hesaplar için geçici yol sunmalıdır. Geçiş sırasında ekip açık onay sürecine ihtiyaç duyar; yerel Markdown desteği tipik belgeler test edildikten sonra eklenebilir.

n8n: izinler ve hata davranışı önemlidir

Belgeler tek başına talebi aşamalarından geçirmez. İş akışı olay almalı, veriyi doğrulamalı, görev oluşturmalı ve sonucu kaydetmelidir. n8n bu katman için bir seçenektir, ancak bu kararlı sürümdeki ilgili değişiklikler belirli düzeltmelerdir.

n8n 2.42.3 iki değişiklik listeliyor: genel üyeler API anahtarlarına değişken kapsamları verebilir; görev çalıştırıcısı işlenmeyen Promise reddinden sonra çalışmayı sürdürür. Bunlar mevcut kurulum ve yapılandırmasına göre değerlendirilmesi gereken hedefli davranış değişiklikleridir.

Görev çalıştırıcısı düzeltmesi, başarısız işlemin başarılı olacağını veya kayıp talebin otomatik kurtarılacağını göstermez. Önerilen akışta birkaç sonuç ayrı kontrol ister: hata sonrası satış yöneticisi ne görür, ara sonuçlar korunur mu ve ikinci teklif oluşturmadan adım tekrarlanabilir mi? Çalıştırıcıyı ayakta tutmakla doğru iş sürecini korumak farklı konulardır.

API kapsam değişikliği de entegrasyona azami erişim vermeyi haklı çıkarmaz. Akış yalnızca fiyat parametrelerini okuyorsa gerçekten hangi izinlere ihtiyacı olduğunu belirleyin. Parametreleri kim değiştirebilir? Değişiklik nerede kaydedilir? Teklif hazırlanırken koşulların hangi sürümü kullanıldı? Bu yanıtlar başarıyla üretilmiş ama yanlış ticari veri içeren belgeleri araştırmaya yardımcı olur.

Pratik yükseltme kararı, düzeltmenin güncel sorunu çözüp çözmediğini ve güncelleme sonrasında akışın kontrolleri geçip geçmediğini sorar. Sürüm numarası; düğümler, dış API’ler ve belirli akışın ayarları arasındaki uyumluluğu göstermez.

Kullanıcı erişimini arka plan hizmeti erişiminden ayırın

Otomasyon, çalışanın işlemiyle hizmetin işlemi arasındaki farkı bulanıklaştırabilir. Satış yöneticisi talebi açıp belgeye erişimi yetkilendirir; arka plan süreci daha sonra korumalı uç noktayı çağırır. Bu istekler farklı yetkilendirme mekanizmaları ve izinler gerektirebilir.

Cloudflare Workers OAuth Provider v1, yetkilendirme sunucusuyla MCP kaynak sunucusunun ayrı Workers üzerinde çalışmasını sağlar. Kaynak sunucusu tokenı genel internete çıkmadan Service Binding üzerinden doğrular. Duyuru MCP 2026-07-28 yetkilendirme belirtimini ve insufficientScope() ile ek kapsam istemeyi de anlatır.

Burada olası uygulama, talebi okuma ve durumunu değiştirme izinlerini ayırmaktır. Araç karar kaydetmek istediğinde sistem her asistana önceden düzenleme izni vermek yerine ek yetkilendirme isteyebilir. Workers’ı ayırmak, yetkilendirme ve kaynak erişimine farklı WAF ve hız sınırlama kuralları uygulamayı da sağlar.

Bu, MCP araçları kullanan mimari için seçenektir. Google’ın önizleme sunucularıyla uyumluluğu göstermez ve olağan akış için MCP’yi zorunlu yapmaz. Uygun izinli doğrudan API çağrısı ihtiyacı karşılıyorsa ek katmanın somut amacı olmalıdır; örneğin birkaç aracın yetkilendirme sistemini paylaşması.

Hizmet isteklerinde kimlik doğrulama hataları öngörülebilir olmalıdır

Arka plan entegrasyonları açık yetkilendirme hataları ister. API ret yerine giriş sayfası döndürürse akış HTML’yi sonuç sayabilir, isteği tekrarlayabilir veya alakasız sorun bildirebilir.

Cloudflare Access’te katı hizmet tokenı kimlik doğrulaması bu davranışı değiştirir. Etkinken, hizmet tokenı başlıkları taşıyan isteğin kimlik doğrulaması veya yetkilendirmesi başarısız olursa giriş sayfasına 302 yönlendirmesi yerine 401 veya 403 döner. İsteği yalnızca Service Auth politikaları yetkilendirebilir; Allow politikaları ve gönderilmiş CF_Authorization çerezi yok sayılır.

Başarılı kimlik doğrulamasından sonra Access de CF_Authorization çerezi vermez. Sonraki istekler hizmet tokenı başlıklarını göndermeye devam etmelidir. 5 Ekim 2026 ve sonrasında oluşturulan yeni Zero Trust kuruluşlarında katı mod varsayılan açıktır ve kapatılamaz. Eski kuruluşlar ayarı kendileri yönetebilir.

Önerilen akışta bu, entegrasyona işleyeceği açık hata verir. Hatayı kaydedebilir ve işlemi erişim kontrolü gerektiren duruma alabilir. Mevcut kurulumu değiştirmeden her istekte hizmet tokenı gönderdiğini ve önceden verilmiş çereze dayanmadığını doğrulayın. Çalışanın OAuth erişimi ve makinenin hizmet tokenları farklı amaçlara hizmet eder; buna göre işlenmelidir.

Tarayıcı kapandıktan sonra çalışmayı sürdürmek

Talep onaylandıktan sonra teklif hazırlama kullanıcının oturumundan uzun sürebilir. Eklerin işlenmesi, hesaplama veya birkaç belgenin birleştirilmesi zaman alabilir. Arayüzü yürütmeden ayırmak, çalışanın işin kabul edildiğini görmesini, sonra sonucunu veya durma nedenini kontrol etmesini sağlar.

1 Ekim Durable Objects yaşam döngüsü değişikliği, sorunun bir bölümüne yardımcı olur. Belirli bekleyen işlemler artık bağlı istemci olmadan da nesneyi etkin tutar: Service Binding istekleri, diğer Durable Objects çağrıları, konteyner izleme, waitUntil() işlevine verilen Promise’lar ve bekleyen zamanlayıcılar.

Bu davranış 2026-10-01 veya sonraki uyumluluk tarihinde varsayılandır; eski tarihler için uyumluluk bayrağı vardır. Her bekleyen işlem, boşta kapanmayı 15 dakikaya kadar engeller. Sınır nesnenin toplam bellekte kalma süresine değil tek işleme uygulanır. İşlem nesneyi etkin tuttuğu sürece süre ücretleri devam eder.

Güncelleme bu nedenle arka plan koordinasyonuna yardım edebilir; ancak kalıcı durum, hata yönetimi veya kapanma sonrası kurtarmanın yerini almaz. Akış hâlâ işlerin nerede saklandığını, tamamlanmanın nasıl kontrol edildiğini ve yeniden denemenin yapılmış adımı nasıl tanıdığını tanımlamalıdır. Uzun beklemeler de maliyet tahminine dahildir.

Değişiklikleri tek süreçte bağlamak

Altı duyuru da kontrollü talep akışı çevresinde değerlendirilebilir. Olası bir sıra şöyledir:

Alım. Talebi ve ekleri saklayın, kimlik atayın, gerekli bilgiyi doğrulayın.
Hazırlık. Taslak belgeyi birleştirin; girdi parametrelerini ve koşulların sürümünü kaydedin.
Netleştirme. Çalışanlar tartışmalı noktaları görüşsün; otomasyon API’lerin doğrulanmış yetenekleri içinde değişiklik önersin.
Onay. Yetkili kişi belirli sürümü onaylar. Talebi sonraki aşamaya taşıma iznini ayrıca kontrol edin.
Arka plan işleme. Son malzemeleri hazırlayın, iş durumunu kaydedin, tamamlanmayı veya hatayı bildirin.
Teslim. Gerekli onaydan sonra teklifi gönderin, gönderilen sürümü kaydedin.

Bu ayrım belirli darboğazı bulmaya yardım eder: eksik veri, gecikmiş karar, erişim hatası veya yürütme arızası. Otomasyonun sınırlarını da belirler. Yorumlar programatik toplanabilir, ancak ticari koşulların açık sorumlusu gerekir. İş açık tarayıcı olmadan sürebilir, ancak sonuç yine saklanmalı ve kontrol edilmelidir.

Süreci desteklemek erişim, sürümler, izleme ve kurtarma altyapısı gerektirir. Bunlar uygulama altyapısı hizmetinde ele alınır. Google Cloud’da Debian vaka çalışması ek bağlam sunar: bu güncellemelerin uygulanmasını veya güncel dağıtım talimatını değil, tarihsel altyapı tasarımını anlatır.

Tek talep türü ve tek belgeyle başlayın. Devreye almadan Google özelliklerinin kullanılabilirliğini, her entegrasyonun izinlerini, hata sonrası denemeleri ve tarayıcı kapandığında iş durumunu kontrol edin. Pilotu onaya kadar geçen süre, manuel veri aktarım sayısı ve müdahale gerektiren işlem payıyla değerlendirin. Böylece teknoloji seçimleri gözlenebilir temele oturur, ürün duyuruları pratik karara dönüşür.

Tamamlanmış veri akışı ne gösterir?

Tamamladığım Mailwizz entegrasyonunda, geri dönen e-posta verisi kişilerle, alan adı özetiyle ve kayıt günlüğüyle eşleştirildi. İşlenen satırlar işaretlendi, adres dışlamalarının tanımlı nedeni vardı. Bu, kaynak veriyi operasyonel sonuca bağlamanın somut örneğidir. Burada anlatılan yeni Google Workspace, n8n veya Cloudflare özelliklerinin kullanıldığını göstermez; tarihsel yayında son çalıştırma takvimi de çözülmemiştir.

Belgeleri, CRM’yi ve görevleri bağlama rehberim, kabul edilen işi korumayı, başarısız devirleri görünür kılmayı ve yeniden denemeleri kontrol etmeyi kapsar. Güncelleme değerlendirmesine şu soruları ekleyin: yeni özellik, akış hata, iptal veya yeniden denemeden sonra anlaşılır kalıyorsa yardımcı olur.

Kaynaklar

Hazırlandı: 6 Ekim 2026.