n8n ile İleri Seviye Workflow Tasarımı: Veri Akışı, Hata Yönetimi, Dosyalar ve Enterprise Yapılar

n8n’de basit otomasyonlar kurmak bir noktaya kadar yeterlidir; ama gerçek dünyada workflow’lar dallanır, birleşir, API’lerle konuşur, hata verir, dosya taşır ve farklı ekiplerin kullanımına açılır. Bu yazıda n8n’i daha sağlam, ölçeklenebilir ve yönetilebilir kullanmak için bilmen gereken ileri seviye yapı taşlarını tek bir bütün olarak ele alacağız.

n8n’de Veri Akışı Nasıl Düşünülmeli?

n8n’de her node bir veri kümesi alır, onu işler ve sonraki node’a aktarır. Node, yani workflow içindeki işlem bloğu. Yani şöyle düşün: her node, elindeki veri paketini ya dönüştüren, ya zenginleştiren, ya filtreleyen ya da dış dünyaya gönderen küçük bir iş istasyonudur.

Basit workflow’larda veri genelde düz bir hat üzerinde ilerler. Fakat workflow büyüdükçe dallar oluşur. Bir veri kümesi farklı koşullara göre ayrılabilir, farklı servislerden ek bilgiler toplanabilir ve sonra tekrar tek hatta birleştirilebilir.

flowchart TD
    A((Başlangıç)) --> B["Veri Al"]
    B --> C{"Koşul Kontrolü"}
    C -->|"Doğru"| D["Birinci Dalı İşle"]
    C -->|"Yanlış"| E["İkinci Dalı İşle"]
    D --> F["Dalları Birleştir"]
    E --> F
    F --> G["Sonraki İşleme Devam Et"]
    G --> H((Bitiş))

Bu diyagram, n8n’de verinin koşula göre iki ayrı kola ayrılıp daha sonra tekrar birleştirilebileceğini gösterir. Büyük workflow’larda bu mantığı doğru kurmak, hem veri kaybını hem de sıra hatalarını engeller.

Node Execution Order: Dallar Hangi Sırayla Çalışır?

Node execution order, yani node’ların çalışma sırası. Yani şöyle düşün: aynı noktadan birden fazla yol çıkıyorsa n8n’in hangi yolu önce yürüyeceğini bilmen gerekir.

n8n 1.0 ve sonrası sürümlerde workflow bir daldaki işlemleri tamamlar, sonra diğer dala geçer. Dallar canvas üzerindeki konumlarına göre değerlendirilir. Üstteki dal önce çalışır. Aynı yükseklikte iki dal varsa soldaki önce çalışır. Bu yüzden görsel düzen sadece estetik değildir; çalışma sırasını da etkileyebilir.

flowchart TD
    A["Başlangıç Node'u"] --> B["Üst Dal - Adım 1"]
    B --> C["Üst Dal - Adım 2"]
    A --> D["Orta Dal - Adım 1"]
    D --> E["Orta Dal - Adım 2"]
    A --> F["Alt Dal - Adım 1"]
    F --> G["Alt Dal - Adım 2"]

Bu yapıdaki çalışma mantığı üst daldan alta doğrudur. n8n önce üst dalı bitirir, ardından orta dala, sonra alt dala geçer.

Bu davranış workflow bazında değiştirilebilir, fakat genelde önerilmez. Çünkü dalların birbirinin çıktısına bağlı olduğu durumlarda çalışma sırasını ayarlamaya güvenmek kırılgan bir çözüm üretir. Daha sağlam yaklaşım, bağımlı dalları Merge node ile açıkça birleştirmektir.

Veriyi Dallara Ayırmak: IF, Switch ve Çoklu Çıkışlar

IF node, yani koşula göre iki ayrı çıkış üreten node. Yani şöyle düşün: gelen her item için “bu koşul doğru mu?” diye sorar ve item’ı doğru ya da yanlış yoluna gönderir.

IF node özellikle iki seçenekli ayrımlarda kullanılır. Örneğin bir kaydın aktif olup olmaması, bir e-posta adresinin kurumsal olup olmaması veya bir sipariş tutarının belirli bir sınırı geçip geçmemesi gibi kontrollerde kullanışlıdır.

Switch node, yani birden fazla koşula göre n farklı çıkış oluşturabilen node. Yani şöyle düşün: IF node iki kapılı bir ayrım yaparken, Switch node çok kapılı bir dağıtım merkezi gibi çalışır. Her item uygun dala gider. Ayrıca fallback branch, yani hiçbir koşula uymayan item’ların gönderileceği yedek dal da tanımlanabilir.

flowchart TD
    A["Gelen Item'lar"] --> B{"Switch Node"}
    B -->|"Durum: Yeni"| C["Yeni Kayıt Akışı"]
    B -->|"Durum: Güncelleme"| D["Güncelleme Akışı"]
    B -->|"Durum: Silme"| E["Silme Akışı"]
    B -->|"Hiçbiri"| F["Fallback Akışı"]

Bu diyagram, Switch node’un item’ları farklı koşullara göre ayrı işlem yollarına yönlendirmesini gösterir. Böylece tek bir veri kaynağından birçok ayrı iş mantığı çıkarılabilir.

Bir node’dan iki ayrı bağlantı çıkarırsan, n8n genellikle aynı çıktıyı iki dala da gönderir. Bu, aynı veri üzerinde iki bağımsız işlem yapmak istediğinde işe yarar. Örneğin bir yandan veriyi rapora yazarken, diğer yandan bir bildirim gönderebilirsin.

Merge Node ile Dalları Yeniden Birleştirmek

Merge node, yani iki farklı input alan ve bu input’ları belirli kurallarla tek çıktıya dönüştüren node. Yani şöyle düşün: iki ayrı masada hazırlanmış veri parçalarını tek masada yeniden düzenlersin.

Merge node’un üç temel kullanım biçimi vardır: Append, Choose ve Combine.

Append, iki input’taki item’ları art arda ekler. Bir dalda 4 item, diğer dalda 6 item varsa çıktı 10 item olur. Bu, ayrılmış kayıtları tekrar tek liste yapmak için kullanışlıdır.

Choose, hangi input’un devam edeceğini seçmeni sağlar. Bazen amaç veri birleştirmek değil, iki dalın da tamamlandığından emin olduktan sonra sadece belirli bir çıktıyla devam etmektir.

Combine, iki input’u alanlara, pozisyona veya tüm kombinasyonlara göre eşleştirerek birleştirir. Bu özellikle veri zenginleştirme için önemlidir.

flowchart TD
    A["Ana Kayıtlar"] --> C["Merge: Combine"]
    B["Ek Bilgi Kaynağı"] --> C
    C --> D["Zenginleştirilmiş Kayıtlar"]

Bu diyagramda bir veri seti başka bir veri kaynağından gelen alanlarla zenginleştirilir. Örneğin kişi kayıtlarına şirket bilgisi, siparişlere müşteri bilgisi veya ürünlere stok bilgisi eklenebilir.

Merge node’u SQL join mantığıyla düşünebilirsin. Inner join, sadece eşleşenleri tutmaya benzer. Left join, birinci input’u koruyup ikinci input’tan eşleşen alanları eklemeye benzer. Right join ise ikinci input’u temel alır. Union benzeri davranış ise Append ile elde edilir.

flowchart LR
    A["Input 1: Kişiler"] --> M{"Merge Combine"}
    B["Input 2: Şirketler"] --> M
    M -->|"Alan eşleşmesi"| C["Kişi + Şirket Bilgisi"]

Burada iki veri seti ortak bir anahtar üzerinden eşleşir. Anahtar, iki tarafta da bulunan e-posta domain’i, müşteri ID’si, sipariş numarası veya ürün kodu olabilir.

Loop Over Items: Büyük Veri ve Rate Limit İçin Kontrollü İşleme

Loop Over Items node, yani gelen item’ları belirli boyuttaki gruplara ayırıp sırayla işleyen node. Yani şöyle düşün: elinde yüzlerce kayıt varsa hepsini aynı anda göndermek yerine küçük gruplar halinde işlersin.

n8n’de çoğu node zaten item bazlı çalışır. Bu yüzden her zaman Loop Over Items kullanmak gerekmez. Fakat bazı durumlarda çok işe yarar. Örneğin bir node tek bir input item alıp çok sayıda output item üretebilir. Google Sheets’ten satır okumak buna iyi bir örnektir. Eğer her input item için ayrı bir sheet okumak istiyorsan, item’ları tek tek döngüye sokmak daha kontrollü olur.

Rate limit, yani bir API’nin belirli sürede izin verdiği istek sınırı. Yani şöyle düşün: bir servis sana “dakikada en fazla 10 istek gönderebilirsin” diyorsa, Loop Over Items ile item’ları gruplara böler, Wait node ile araya bekleme süresi koyar ve sınırı aşmadan ilerlersin.

flowchart TD
    A["Çok Sayıda Item"] --> B["Loop Over Items"]
    B --> C["API İsteği Gönder"]
    C --> D["Wait Node"]
    D --> B
    B -->|"Tüm Item'lar Bitti"| E["Sonraki Adım"]

Bu diyagram, API rate limit olan sistemlerde item’ların kontrollü biçimde işlenmesini gösterir. Döngü içinde her batch işlenir, gerekirse beklenir ve sonra sıradaki batch’e geçilir.

n8n arayüzünde loop çalışırken farklı run’ları ayrı ayrı görebilirsin. Bu, hangi item’ın hangi döngüde nasıl değiştiğini anlamak için çok değerlidir.

Expressions: n8n İçinde Dinamik Değerlerle Çalışmak

Expression, yani node alanlarına dinamik değer yazmak için kullanılan küçük JavaScript parçaları. Yani şöyle düşün: sabit bir metin yazmak yerine, önceki node’dan gelen değeri alıp o alana otomatik yerleştirirsin.

n8n’de expression’lar çift süslü parantez içinde yazılır. Önceki node verilerine ulaşabilir, basit matematik işlemleri yapabilir, string parçalayabilir, tarih hesaplayabilir veya n8n’in hazır veri dönüşüm fonksiyonlarını kullanabilirsin.

Örneğin bir e-posta adresinden domain çıkarmak, iki sayıyı toplamak, boş alan kontrolü yapmak veya array içindeki tekrarları temizlemek expression ile yapılabilir.

Data transformation functions, yani n8n’in hazır veri dönüştürme fonksiyonları. Yani şöyle düşün: her küçük işlem için Code node yazmak yerine, n8n’in hazır fonksiyonlarıyla veriyi hızlıca şekillendirirsin. isEmpty, hasField, removeDuplicates, array farkı alma ve domain çıkarma gibi fonksiyonlar bu kategoriye girer.

Tarih ve Saat İşlemleri: Luxon Kullanımı

Luxon, JavaScript için tarih ve saat işlemlerini kolaylaştıran bir kütüphane. Yani şöyle düşün: tarihleri düz string gibi parçalamak yerine, gerçekten tarih nesnesi gibi ele almanı sağlar.

n8n expression’larında $now ile mevcut tarih ve saate erişebilirsin. $today genellikle günün başlangıcını ifade eden tarih değerini verir. Tarihleri belirli formattan okumak, string’e çevirmek veya yerel formatta göstermek için Luxon fonksiyonlarından yararlanabilirsin.

Burada dikkat etmen gereken nokta şu: n8n node’ları arasında tarih değerleri çoğu zaman string olarak taşınır. Bir tarih üzerinde hesaplama yapacaksan önce onu tekrar tarih nesnesine çevirmek gerekebilir.

flowchart TD
    A["Tarih String'i"] --> B["Luxon ile DateTime Nesnesine Çevir"]
    B --> C["Hesaplama veya Formatlama Yap"]
    C --> D["String Olarak Sonraki Node'a Aktar"]

Bu akış, tarih bilgisinin n8n içinde nasıl güvenli şekilde işlenebileceğini gösterir. Tarihi sadece metin gibi taşımak basittir, ama dönüşüm yaparken Luxon gibi bir araç kullanmak daha sağlamdır.

Code Node: n8n’in Esneklik Alanı

Code node, yani JavaScript veya Python kodu çalıştırarak input item’larını dönüştüren node. Yani şöyle düşün: hazır node’ların yetmediği yerde küçük bir özel işlem motoru ekliyorsun.

Code node iki modda çalışabilir. Run once for all items modunda tüm input item’ları aynı anda ele alınır ve çıktı olarak bir array döndürmen gerekir. Run once for each item modunda ise node her item için ayrı çalışır ve her çalışmada tek bir JSON object döndürmen gerekir.

Bu ayrım önemlidir. Eğer tüm item’ların toplamını, ortalamasını, dağılımını veya tekrarlarını hesaplamak istiyorsan Run once for all items daha uygundur. Eğer her item’a yeni bir alan eklemek veya item bazlı hesaplama yapmak istiyorsan Run once for each item daha temizdir.

flowchart TD
    A["Input Item'lar"] --> B{"Code Node Modu"}
    B -->|"Run once for all items"| C["Tüm Liste Üzerinden Hesaplama"]
    B -->|"Run once for each item"| D["Her Item İçin Ayrı İşlem"]
    C --> E["Array Halinde Output"]
    D --> F["Tekil JSON Output"]

Bu diyagram, Code node’un iki farklı çalışma biçimini gösterir. Doğru modu seçmek hem kodu sadeleştirir hem de output hatalarını azaltır.

Code node’da $input.all() ile tüm input item’larına erişebilirsin. $json ise mevcut item’ın JSON verisini ifade eder. Kod mutlaka geçerli bir output döndürmelidir. Hiçbir şey döndürmek istemiyorsan bile boş bir JSON object içeren bir array döndürmek gerekir.

Console logging, yani kod içinden ara değerleri loglama. Yani şöyle düşün: hesaplamanın hangi adımda yanlış gittiğini görmek için geçici kontrol noktaları koyarsın. Özellikle toplam, ortalama veya döngü içi dönüşümlerde console.log hata ayıklamayı hızlandırır.

HTTP Request Node: API’lerle Çalışmanın Ana Kapısı

HTTP Request node, yani n8n içinden HTTP istekleri göndermeni sağlayan node. Yani şöyle düşün: Postman’da manuel yaptığın API çağrısını workflow içine koyarsın.

Bu node ile URL, method, query parameter, header, body, authentication, timeout ve pagination gibi ayarları yapılandırabilirsin. API ile konuşan workflow’larda en sık kullanılan ileri seviye node’lardan biridir.

Pagination, yani API sonucunun sayfalar halinde gelmesi. Yani şöyle düşün: servis sana 10.000 kayıt yerine önce ilk 100 kaydı verir, sonra devam sayfasına gitmeni ister. HTTP Request node’un gelişmiş ayarlarıyla bu sayfalama mantığını otomatik hale getirebilirsin.

Node’un güçlü taraflarından biri de başka node’lara ait credential tiplerini kullanabilmesidir. Credential, yani API anahtarı, OAuth bağlantısı veya kimlik doğrulama bilgisidir. Yani şöyle düşün: bir servisin hazır credential yapısı varsa, HTTP Request node ile aynı yetkilendirmeyi tekrar elle kurmadan kullanabilirsin.

Import cURL özelliği de pratik bir hızlandırıcıdır. Bir API dokümantasyonunda cURL örneği varsa onu node’a yapıştırarak method, URL, header ve body alanlarının otomatik dolmasını sağlayabilirsin.

sequenceDiagram
    participant W as "n8n Workflow"
    participant H as "HTTP Request Node"
    participant A as "Harici API"
    W->>H: "URL, header, body ve credential gönder"
    H->>A: "API isteği yap"
    A-->>H: "Yanıt döndür"
    H-->>W: "JSON veya dosya çıktısı üret"

Bu sequence diagram, n8n’in harici API ile nasıl konuştuğunu gösterir. HTTP Request node, workflow ile dış servis arasında aracı görevini üstlenir.

Pinning Data: Workflow Geliştirirken Zaman Kazanmak

Pinned data, yani bir node’un test çıktısını sabitleyip tekrar tekrar kullanmak. Yani şöyle düşün: pahalı, yavaş veya zahmetli bir işlemi her testte yeniden çalıştırmak yerine çıktısını geçici olarak masaya koyup onunla çalışmaya devam edersin.

Bu özellik özellikle webhook, API çağrısı, uzun süren veri çekme işlemi veya harici sistem tetiklemeleri sırasında çok işe yarar. Bir webhook’u tekrar tekrar manuel göndermek yerine ilk çıktıyı pin’leyip sonraki node’ları hızlıca geliştirebilirsin.

Pinned data sadece test execution sırasında kullanılır. Production çalışmalarda node normal şekilde çalışır. Bu ayrım önemlidir, çünkü pin’lenmiş veri canlı otomasyonu etkilemez.

flowchart TD
    A["Harici Sistem veya Webhook"] --> B["Node Output"]
    B --> C["Pinned Data"]
    C --> D["Sonraki Node'ları Test Et"]
    A -.->|"Production'da tekrar çalışır"| B

Bu yapı, pinned data’nın geliştirme sürecinde test verisi gibi davrandığını gösterir. Canlı çalışmada ise gerçek veri akışı devam eder.

Edit Output Data: Edge Case Test Etmenin Hızlı Yolu

Edit output data, yani bir node’un test çıktısını elle düzenleme özelliği. Yani şöyle düşün: gerçek sistemden özel bir hata durumu üretmeye çalışmak yerine, node çıktısında küçük değişiklik yapıp workflow’un nasıl tepki verdiğini test edersin.

Örneğin bir alanı null yapabilir, sayı beklenen yere string koyabilir, eksik alan senaryosu oluşturabilir veya önceki başarısız execution’dan veri kopyalayıp workflow’u o veriyle yeniden test edebilirsin.

Bu özellik pinned data ile birlikte çok güçlü hale gelir. Önce veriyi pin’lersin, sonra output’u düzenleyerek farklı edge case’leri hızlıca denersin.

Mockaroo gibi mock data araçları da burada işe yarar. Mock data, yani gerçek sisteme bağlı olmadan üretilmiş sahte ama gerçekçi test verisi. Yani şöyle düşün: 100 farklı kullanıcı, e-posta, ID veya IP adresi üretip workflow’un geniş veri setlerinde nasıl davrandığını görebilirsin.

Subworkflow: Tekrar Kullanılabilir Workflow Parçaları

Subworkflow, yani bir workflow’un başka bir workflow tarafından çağrılması. Yani şöyle düşün: sık kullandığın bir işlem dizisini kopyala yapıştır yapmak yerine, onu ayrı bir fonksiyon gibi tanımlarsın.

n8n’de Execute Workflow node, başka bir workflow’u çağırır. Çağrılan workflow ise When Called by Another Workflow trigger ile başlar. Ana workflow’dan gelen input, subworkflow’un giriş verisi olur. Subworkflow tamamlandığında son node’un çıktısı ana workflow’a geri döner.

flowchart TD
    subgraph AnaWorkflow["Ana Workflow"]
        A["Veriyi Hazırla"] --> B["Execute Workflow Node"]
        B --> C["Geri Dönen Sonuçla Devam Et"]
    end

    subgraph SubWorkflow["Subworkflow"]
        D["When Called by Another Workflow"] --> E["Ortak İş Mantığı"]
        E --> F["Son Node Çıktısı"]
    end

    B -.-> D
    F -.-> B

Bu diyagram, ana workflow ile subworkflow arasındaki veri alışverişini gösterir. Subworkflow, ortak kullanılan işlem bloklarını merkezi hale getirir.

Subworkflow kullanmanın en büyük faydası bakım kolaylığıdır. Örneğin müşteri lookup, kullanıcı zenginleştirme, sipariş doğrulama veya standart bildirim üretme gibi işlemler birçok workflow’da kullanılabilir. Bu mantığı tek bir subworkflow’a taşırsan değişiklik gerektiğinde sadece bir yeri güncellersin.

Burada iki kritik nokta var. İlk olarak input alan adlarını standartlaştırmalısın. email bekleyen bir subworkflow’a Email gönderirsen hata alabilirsin. İkinci olarak subworkflow’un son node’una dikkat etmelisin; çünkü ana workflow’a dönen veri son node’un çıktısıdır.

Subworkflow içinde note kullanarak beklenen input formatını yazmak da iyi bir pratiktir. Örneğin “top-level id veya email alanı beklenir” gibi kısa bir açıklama, ekip içi kullanımı kolaylaştırır.

Error Workflow: Hataları Merkezi Yönetmek

Error workflow, yani workflow hatalarını yakalayıp standart bir işlemden geçiren özel workflow. Yani şöyle düşün: her workflow kendi başına sessizce patlamak yerine, hata olduğunda merkezi bir alarm sistemine haber verir.

Error Trigger node, hata veren workflow hakkında bilgiler üretir. Workflow adı, execution ID, hata tipi, hata mesajı, hata veren node ve failed execution link’i gibi veriler bu çıktının içinde bulunur. Bu bilgilerle standart bir hata bildirimi oluşturabilirsin.

flowchart TD
    A["Bir Workflow Hata Verir"] --> B["Error Trigger"]
    B --> C["Workflow Bilgisini Zenginleştir"]
    C --> D["Owner Bilgisini Bul"]
    D --> E["İletişim Kanalını Seç"]
    E --> F["Slack veya Email Bildirimi Gönder"]

Bu diyagram, merkezi error workflow’un temel mantığını gösterir. Hata sadece yakalanmaz; ilgili kişiye anlamlı bilgilerle yönlendirilir.

Büyük n8n kurulumlarında workflow’ların sahiplerini etiketlerle belirlemek işe yarar. Örneğin workflow tag’lerinde owner adı tutulabilir. Error workflow hata alan workflow’un detaylarını n8n node ile çekip tag bilgisinden owner’ı bulabilir. Sonra bir tablo, code node veya veri kaynağı üzerinden owner’ın e-posta ya da Slack bilgisine ulaşabilir.

Hata önceliği de üretilebilir. Örneğin 500 tipi hatalar bazen dış servisin geçici problemine işaret eder ve düşük öncelikli olabilir. 400 tipi hatalar ise genellikle request formatı, eksik alan veya yanlış parametre gibi workflow tarafında düzeltilmesi gereken sorunlardır. Bu yüzden daha yüksek öncelik alabilir.

Daha gelişmiş bir yapıda her owner için ayrı bir subworkflow çağrılabilir. Böylece bir kişi Slack bildirimi isterken başka biri email, başka biri ise kendi logging sistemine kayıt isteyebilir.

Baştan Sona Örnek Bir Workflow Tasarımı

İleri seviye n8n kullanımını en iyi anlatan şey uçtan uca bir workflow’dur. Düşünelim ki kullanıcı bir form üzerinden şirket URL’leri giriyor. Workflow bu URL’leri tek tek işliyor, People Data Labs API ile şirket bilgilerini zenginleştiriyor, Avrupa’daki şirketleri Google Sheets’e ekliyor ve sonunda Slack üzerinden özet gönderiyor.

Form Trigger, yani n8n’in form üzerinden veri almasını sağlayan trigger. Yani şöyle düşün: teknik olmayan bir kullanıcıya küçük bir giriş ekranı verirsin, o da workflow’u veriyle başlatır.

İlk adımda kullanıcıdan virgülle ayrılmış URL listesi alınır. Bu veri tek bir string olarak gelir. Edit Fields node ile bu string array’e çevrilir. Sonra Split Out node ile array içindeki her URL ayrı item haline getirilir.

flowchart TD
    A["Form Trigger"] --> B["URL String'ini Al"]
    B --> C["Edit Fields ile Array'e Çevir"]
    C --> D["Split Out ile Ayrı Item'lara Böl"]
    D --> E["Loop Over Items"]
    E --> F["People Data Labs API"]
    F --> G{"Status 200 mü?"}
    G -->|"Hayır"| H["Stop and Error"]
    G -->|"Evet"| I["Ana Alanları Top Level'a Taşı"]
    I --> J{"Kıta Europe mu?"}
    J -->|"Evet"| K["Google Sheets'e Append Et"]
    J -->|"Hayır"| L["Atla"]
    K --> M["Summarize Node"]
    M --> N["Slack Bildirimi"]

Bu diyagram, formdan Slack bildirimine kadar tam workflow akışını gösterir. Veri önce parçalanır, sonra API ile zenginleştirilir, filtrelenir, kaydedilir ve özetlenir.

API çağrısında HTTP Request node kullanılır. Credential generic header olarak ayarlanabilir. SQL benzeri query içinde her item’ın URL değeri expression ile dinamik olarak yerleştirilir. Böylece her turda farklı şirket sorgulanır.

Hata kontrolü için API yanıtındaki status değeri incelenir. Status 200 değilse Stop and Error node ile workflow bilinçli olarak durdurulur. Bu, sessiz veri bozulmasını engeller.

Zengin JSON çıktıları genellikle çok derin olur. Bu yüzden Edit Fields ile ihtiyaç duyulan alanları top-level hale getirmek iyi pratiktir. Şirket adı, çalışan sayısı, ülke, kıta ve toplam fonlama gibi alanlar sonraki node’larda daha kolay kullanılır.

Summarize node, yani item’lar üzerinde sayım, toplam veya özet hesaplama yapan node. Yani şöyle düşün: Google Sheets’e kaç kayıt eklendiğini öğrenmek için ayrıca kod yazmadan hazır bir özet çıkarırsın.

Slack node’da blocks kullanmak daha zengin bildirim üretir. Blocks, yani Slack mesajını metin, buton ve bölümlerle yapılandırma biçimi. Yani şöyle düşün: düz mesaj yerine “şu kadar kayıt eklendi” bilgisini ve Google Sheets linkini butonla sunabilirsin.

Dosyalarla Çalışmak: Binary Data Mantığı

Binary data, yani dosya içeriğinin n8n item’ları içinde dosya olarak taşınması. Yani şöyle düşün: JSON alanlarında metin ve sayı taşırken, binary alanda görsel, PDF, zip veya benzeri dosyaları taşırsın.

Dosya işleyen node’larda output panelinde Binary view görünür. Bu görünümde dosya adı, uzantı, MIME type, boyut ve benzeri bilgiler yer alır. Görseller veya belgeler doğrudan önizlenebilir ya da indirilebilir. Eğer item sadece dosya taşıyorsa JSON, table ve schema görünümleri boş olabilir.

HTTP Request node ile dosya indirebilirsin. Bunun için response format file olarak ayarlanır ve binary property adı belirlenir. Örneğin logo veya document gibi bir alan adı kullanılabilir.

flowchart TD
    A["HTTP Request ile Dosya Al"] --> B["Binary Output"]
    B --> C{"Dosya İşlemi"}
    C -->|"Sıkıştır"| D["Compress Node"]
    C -->|"Aç"| E["Decompress Node"]
    C -->|"Diske Yaz"| F["Read/Write Files"]
    C -->|"JSON'a Çevir"| G["File - JSON Dönüşümü"]

Bu diyagram, n8n’de dosya işleme sırasında kullanılabilecek temel yolları gösterir. Dosyalar binary alanda taşınır ve ihtiyaca göre sıkıştırılır, açılır, diske yazılır veya dönüştürülür.

Birden fazla dosyayı tek item içinde farklı binary property’ler olarak taşıyabilirsin. Örneğin bir item’da hem logo hem report dosyası bulunabilir. Compress node ile bu dosyaları tek bir zip dosyasına çevirmek mümkündür.

Tersi durumda bir zip dosyası indirip Decompress node ile içindeki dosyaları açabilirsin. Decompression sonrası tek item içinde file_0, file_1, file_2 gibi birden fazla binary alan oluşabilir. Eğer bu dosyaları tek tek işlemek istiyorsan, Code node ile her binary alanı ayrı item’a ayırman gerekebilir.

flowchart TD
    A["Zip Dosyası"] --> B["Decompress Node"]
    B --> C["Tek Item İçinde Birden Fazla Binary Alan"]
    C --> D["Code Node ile Split"]
    D --> E["Her Dosya Ayrı Item"]
    E --> F["Loop veya Sonraki İşlem"]

Bu diyagram, zip içindeki dosyaları ayrı ayrı işlenebilir hale getirme mantığını gösterir. Tek item’daki çoklu binary alanlar ayrıştırıldığında workflow daha esnek hale gelir.

Enterprise Özellikler: Ekip, Ortam ve Güvenlik Yönetimi

n8n Enterprise özellikleri, workflow yazmaktan çok workflow’ları güvenli ve sürdürülebilir biçimde işletmekle ilgilidir. Enterprise feature, yani büyük ekipler ve kritik iş süreçleri için ek yönetim özelliği. Yani şöyle düşün: tek kişinin kullandığı otomasyondan, şirketin güvendiği otomasyon platformuna geçişte gereken kontrol katmanlarıdır.

User management tarafında üç temel rol vardır: owner, admin ve member. Owner tüm instance üzerinde en yüksek yetkiye sahiptir. Kullanıcı yönetimi, workflow ve credential paylaşımı, source control gibi alanlara erişebilir. Ancak hassas credential değerlerini düz metin olarak okuyamaz. Admin rolü owner’a yakındır ama owner rolünü yönetemez ve bazı yönetim alanlarına erişimi sınırlıdır. Member ise kendi workflow ve hesap işlemlerini yürüten standart kullanıcıdır.

Execution Data node, yani execution geçmişinde sonradan aramak istediğin özel alanları kaydetmeni sağlayan node. Yani şöyle düşün: binlerce çalışma kaydı arasında belirli bir sipariş ID’sini bulmak için o ID’yi execution metadata’sına işlersin.

flowchart TD
    A["Workflow Çalışır"] --> B["Order ID veya User ID Al"]
    B --> C["Execution Data Node"]
    C --> D["Execution Geçmişine Aranabilir Alan Kaydet"]
    D --> E["Sonradan Key-Value ile Filtrele"]

Bu diyagram, execution data kaydetmenin amacını gösterir. Kritik ID’leri kaydedersen geçmiş execution’ları tek tek açmak zorunda kalmazsın.

Source control, yani n8n workflow’larını Git tabanlı sürüm kontrolüne bağlama özelliği. Yani şöyle düşün: workflow değişikliklerini kod gibi takip eder, geliştirme ve üretim ortamlarını ayrı tutarsın.

Development ortamında workflow’ları değiştirip test edebilir, production ortamında ise işin canlı çalışan kararlı halini koruyabilirsin. Bu yaklaşım özellikle müşteri etkileyen, stok, sipariş, ödeme, bildirim veya operasyon süreçlerini yöneten workflow’larda önemlidir.

flowchart LR
    A["Development n8n"] --> B["Git Branch: dev"]
    B --> C["Review ve Test"]
    C --> D["Git Branch: production"]
    D --> E["Production n8n"]

Bu diyagram, n8n ortamlarının Git branch’leriyle nasıl yönetilebileceğini gösterir. Değişiklikler doğrudan canlı sisteme değil, kontrollü bir süreçten geçerek production’a taşınır.

Custom variables, yani workflow’lar arasında ortak değerleri environment bazlı saklama özelliği. Yani şöyle düşün: aynı workflow development’ta test veritabanını, production’da gerçek veritabanını kullanır; ama workflow içindeki expression değişmez.

Variables read-only yapıdadır ve key-value olarak tanımlanır. Key uzunluğu ve value uzunluğu için sınırlar bulunur. Expression veya Code node içinde $vars üzerinden okunabilir. URL, IP adresi, şirket ID’si veya ortam bazlı endpoint gibi değerler için çok uygundur.

External secrets, yani credential değerlerini n8n veritabanı yerine dış bir secret vault içinde saklama yaklaşımı. Yani şöyle düşün: hassas bilgileri merkezi bir kasada tutar, n8n’in sadece gerektiğinde o değeri kullanmasını sağlarsın.

n8n zaten credential’ları şifreli saklar, fakat external secrets ek güvenlik ve merkezi yönetim sağlar. HashiCorp Vault gibi araçlarla development ve production için ayrı secret environment’ları kurulabilir. Böylece aynı credential adı farklı ortamda farklı gerçek değere bağlanabilir.

Log streaming, yani n8n olaylarını dış log ve monitoring sistemlerine aktarma özelliği. Yani şöyle düşün: n8n’de olan biteni kendi alarm, denetim ve gözlemleme sistemine taşırsın.

Log streaming destination olarak webhook, Sentry veya syslog gibi hedefler seçilebilir. Event türleri arasında audit olayları, AI workflow olayları, node execution olayları ve farklı sistem olayları bulunabilir. Audit event’ler compliance gereksinimleri için özellikle değerlidir ve anonimleştirme seçenekleriyle kullanılabilir.

flowchart TD
    A["n8n Instance"] --> B{"Log Streaming"}
    B --> C["Webhook Destination"]
    B --> D["Sentry"]
    B --> E["Syslog"]
    C --> F["Monitoring ve Alerting"]
    D --> F
    E --> F

Bu diyagram, n8n event’lerinin dış gözlemleme sistemlerine nasıl taşınabileceğini gösterir. Böylece hata, denetim ve operasyon takibi n8n arayüzüyle sınırlı kalmaz.

Sağlam n8n Workflow’ları İçin Tasarım Mantığı

İleri seviye n8n kullanımı sadece daha fazla node bilmek değildir. Asıl mesele, verinin nereden geldiğini, nasıl şekil değiştirdiğini, hangi dalda neden ilerlediğini ve hata olduğunda kimin ne yapacağını net tasarlamaktır.

Dallanma kullanıyorsan Merge node ile tekrar birleşme noktasını açık kurmalısın. API kullanıyorsan HTTP Request node’un response, pagination, credential ve error davranışlarını düşünmelisin. Büyük veri veya rate limit varsa Loop Over Items ve Wait node ile kontrollü ilerlemelisin. Aynı işlem birçok workflow’da tekrar ediyorsa subworkflow’a taşımalısın. Canlı sistemde güvenilirlik istiyorsan error workflow, execution data, source control, variables, external secrets ve log streaming gibi özellikleri mimarinin parçası yapmalısın.

flowchart TD
    A["Güvenilir Workflow"] --> B["Açık Veri Akışı"]
    A --> C["Kontrollü API Kullanımı"]
    A --> D["Merkezi Hata Yönetimi"]
    A --> E["Tekrar Kullanılabilir Subworkflow'lar"]
    A --> F["Test ve Mock Data Pratikleri"]
    A --> G["Enterprise Yönetim Katmanları"]

Bu diyagram, iyi tasarlanmış bir n8n sisteminin temel parçalarını özetler. Her parça tek başına faydalıdır, ama birlikte kullanıldığında workflow’lar daha bakımı kolay ve güvenilir hale gelir.

Özet

n8n’de ileri seviye workflow geliştirmek, veriyi sadece bir node’dan diğerine taşımaktan ibaret değildir. Dalların hangi sırayla çalıştığını bilmek, IF ve Switch ile veriyi doğru ayırmak, Merge node ile tekrar güvenli biçimde birleştirmek, Loop Over Items ile büyük veri ve API limitlerini yönetmek gerekir. Expression, Luxon, Code node ve HTTP Request node gibi araçlar workflow’a ciddi esneklik katar. Pinning data ve edit output data geliştirme hızını artırırken, subworkflow’lar tekrar eden mantığı merkezi hale getirir. Error workflow, dosya işleme ve Enterprise özellikleri ise n8n’i bireysel otomasyon aracından daha yönetilebilir bir operasyon platformuna taşır.

Kaynakça

• https://www.youtube.com/playlist?list=PLlET0GsrLUL5bxmx5c1H1Ms_OtOPYZIEG