CRM kesintisinden sonra talepler nasıl güvenle yeniden işlenir?

Kesinti, kaydın oluşmadığı anlamına gelmez

CRM kaydı oluşturulmuş, fakat yanıt bağlantı hatası nedeniyle otomasyona ulaşmamış olabilir. Bu durumda sonuç başarısız değil, belirsizdir. FuLab’ın önerdiği tasarımda her talep için kaynak kimliği ve işlem anahtarı saklanır. Yeniden yazmadan önce hedef CRM’de bu anahtarla kayıt aranır. Aynı e-postanın tekrar alınması ile aynı müşterinin yeni talebi birbirinden ayrılır.

Önce uzlaştırma, sonra yeniden işleme

İş günlüğünde talep alındı, CRM sonucu belirsiz, CRM doğrulandı, yanıt onaylandı ve yanıt gönderimi doğrulandı durumlarını ayrı tutun. CRM kaydı bulunursa kimliğini günlüğe bağlayıp sonraki eksik adıma geçin. Bulunamazsa kontrollü yeniden yazma değerlendirilir. Arama servisi de erişilemiyorsa ikinci kayıt oluşturmak yerine işi bekletin. CRM benzersiz alan veya idempotency desteği sunuyorsa ürünün kendi koşullarına göre kullanın; yalnızca ön kontrol eşzamanlı iki yazmayı engellemez. Böyle bir destek yoksa tek işleyici veya kilit ve uzlaştırma tasarımı ayrıca test edilmelidir.

Hata bildiriminin resmî mekanizması

n8n’de Error Trigger ile başlayan bir hata iş akışı, ana akışın ayarlarından ilişkilendirilebilir. Stop And Error, seçilen koşullarda yürütmeyi hata durumuna düşürmek için kullanılabilir. Hata bilgisindeki execution.id ve execution.url her durumda bulunmaz; tetikleyici hatalarında farklı veri yapısı gelebilir. Bildirim metni bu alanlar eksik olduğunda da anlaşılır kalmalıdır. Bunlar 5 Ekim 2026’da doğrulanan resmî ürün davranışlarıdır.

Tekrar denemeyi görev türüne bağlayın

FuLab önerisi: geçici bağlantı sorununu, yetki hatasını ve geçersiz alanı farklı kuyruklara ayırın. Yeniden deneme sayısı ve bekleme süresi, bağlı hizmetin kurallarıyla belirlenir; burada evrensel bir sayı önerilmiyor. Deneme sınırı dolduğunda talep, sorumlu kişi ve son durumuyla inceleme kuyruğunda kalır. E-posta gönderiminin sonucu belirsizse CRM kaydının doğrulanması ikinci mesaj göndermeye izin vermez. Gönderim hizmetinin kayıtları ayrıca uzlaştırılmalıdır.

Manuel test yeterli değildir

Resmî Error Trigger belgesine göre hata akışı elle çalıştırılan denemede tetiklenmez; otomatik yürütmede hata oluşması gerekir. Pilotun ayrı test ortamında otomatik bir tetikleyiciyle kontrollü hata üretin. CRM yazıldıktan sonra bağlantının kopması, aynı talebin iki kez gelmesi, eşzamanlı işlem ve bildirimin başarısız olması senaryolarını deneyin. Test sonrasında hedef CRM kaydı ve gönderim günlüğünü tekrar okuyun.

Ne ölçülecek?

Mükerrer kayıt, mükerrer gönderim, belirsiz kalan işlem, kurtarma süresi ve insan düzeltme süresini raporlayın. Kurtarılan talep, hedef kaydı ve gerekli gönderimi doğrulanmış taleptir; yalnızca iş akışının yeşil görünmesi yeterli değildir. Bu yazı önerilen bir mühendislik yöntemidir. FuLab müşterisinden ölçülmüş sonuç, tarife veya tasarruf yüzdesi sunmuyor.

Kaynaklar

• n8n — Handle errors gracefully
• n8n — Error Trigger