POWER AUTOMATE HATA İZLEME
Power Automate akışları kuruldukları gün çalışırlar; sonra unutulurlar. Üç ay sonra biri "şu mail neden artık gelmiyor" diye sorduğunda akışın bir aydır hata verdiği fark edilir. Akış başarısız olur, başarısız olduğunu bilen olmaz. Hata izleme bu görünmez başarısızlıkları görünür kılan disiplindir; akış kurulduktan sonra sessizce çürümesini önler.
Akış Hatasının Çeşitleri
Power Automate'te hatalar üç ana kategoride gelir:
- Bağlantı hataları: Connector'ın bağlantısının kopması veya yetkilendirmenin sona ermesi. Örneğin SharePoint'e bağlanan kullanıcının paroladaki süre dolduğunda akış hata verir.
- Veri hataları: Beklenen formatın gelmemesi veya null değer gibi durumlar. E-postada beklenen alan boşsa akış patlar.
- Mantık hataları: Akışın kendi kurgusundaki kalıcı sorunlar. If koşulu yanlış yazılmış, sayı toplaması string olarak yapılmıştır.
Bu üç kategori farklı çözüm yaklaşımları ister. Bağlantı hataları kullanıcı eylemini, veri hataları akış içinde kontrolü, mantık hataları akış güncellemesini gerektirir. Doğru kategoriye sokmadan müdahale gereksiz iş üretir.
Run History
Power Automate'in temel hata izleme aracı her akışın Run History sayfasıdır. Bu sayfa akışın son otuz günlük çalıştırmalarını listeler; başarılı, başarısız, devam eden, iptal edilen durumlarıyla. Başarısız bir çalıştırmaya tıklandığında her adımın detayı görünür, hangi adımda hatanın oluştuğu işaretlenir, hata mesajı okunabilir.
Bu görünüm tek bir akış için yeterlidir ama yüzlerce akış olan bir kurumda her birini ayrı ayrı kontrol etmek imkansızdır. Bu yüzden merkezi izleme katmanına ihtiyaç vardır; her hata bir log tablosuna düşer, dashboard'da görünür, kritik hatalarda bildirim çalışır.

Configure Run After
Power Automate'te en güçlü hata yönetim aracı "Configure Run After" özelliğidir. Her aksiyonun önceki aksiyonların hangi durumlarına göre çalışacağı ayarlanır: başarılı, başarısız, atlandı, zaman aşımı. Bu özellik sayesinde bir adım başarısız olduğunda devam etmek yerine kontrollü bir hata yolu izlenebilir.
Tipik kullanım şudur: Try adımları normal akışı yapar, sonra bir Catch bloğu hata oluşan adımlar için yapılandırılır. Catch bloğu hatayı loglara yazar, ilgili kişiye bildirir, gerekiyorsa düzeltme akışını tetikler. Bu yapı try/catch programlama desenini Power Automate'e taşır ve akışın çökmek yerine düzgün son bulmasını sağlar.
Try / Catch deseninin Scope yapısı:
[Try Scope]
- Get items (SharePoint)
- Apply to each
- Send email
- Update item
[Catch Scope] // Run After: Try Scope = failed, timed out
- Compose: workflow().run.name
- Add row to LogTable
AkisAdi: workflow().name
CalistirmaID: workflow().run.name
HataMesaji: result('TryScope')
Zaman: utcNow()
- Post message in Teams (Otomasyon kanalı)Scope ile Yapılandırma
Configure Run After'ı tek tek aksiyonlarda kullanmak hızla karışıklık yaratır. Daha temiz yapı Scope (kapsam) kontrolüyle gelir. Scope birden çok aksiyonu gruplandırır; Try Scope normal akışı içerir, Catch Scope sadece Try başarısız olursa çalışır. Bu yapı kod blokları gibi mantıksal olarak organize edilmiş bir akış oluşturur.
Scope'lar iç içe de geçebilir. Bir ana Try Scope ve bir Catch Scope yapısı içinde her ikisinde de daha küçük Try-Catch yapıları olabilir. Bu desen büyük ve karmaşık akışlarda hata yönetimini kalıcı hale getirir.
Merkezi Hata Log Tablosu
Hata izleme için merkezi bir SharePoint listesi veya Dataverse tablosu kurulur. Konunun resmi ve ayrıntılı anlatımı Power Automate resmi belgelerinde bulunur. Her akışın Catch bloğu bu tabloya bir kayıt ekler; akış adı, çalıştırma kimliği, hata mesajı, zaman, etkilenen veri özeti. Bu tablo zamanla kurumun otomasyon sağlığının panosu haline gelir.
Hata log tablosunun üstüne Power BI raporu kurulur. Hangi akışlar en sık hata verir, hangi saatlerde yoğunlaşır, hangi hata mesajları tekrar eder, çözüm süresi nedir gibi sorular bu pano üzerinden cevaplanır. Bu görünürlük otomasyon ekibinin önceliklerini şekillendirir.
Otomatik Yeniden Deneme
Bazı hatalar geçicidir; ağ kesintisi, API limit aşımı, bağlantı zaman aşımı. Bu tip hatalar için akış otomatik yeniden deneme (retry) yapacak şekilde kurulur. HTTP aksiyonlarında ve birçok connector'da yerleşik retry policy seçenekleri bulunur; default genelde dört kez tekrar dener, üstel bekleme ile.
Manuel retry da kurgulanabilir. Catch bloğu hatayı yakaladıktan sonra Do Until döngüsüyle belirli sayıda aksiyon tekrar denenir. Bu yaklaşım connector'ın yerleşik retry'sini geçer ama akış mantığını karmaşıklaştırır; sadece gerçekten gerekli olduğunda kullanılır.
Uyarı Mekanizması
Hata loglarını sadece tablodan okumak yetmez; gerçek zamanlı uyarı kanalları kurulur. Kritik akış başarısız olursa otomasyon ekibine Teams mesajı gider, e-posta atılır. Bu uyarılar bildirim standartlarına uygun olur; her hata için ayrı mesaj değil, eşik aşıldığında özet mesaj gönderilir.
Uyarı seviyeleri belirlenir. P1 acil — kritik iş kesintisi var, mobil push dahil tüm kanallar tetiklenir. P2 önemli — düzeltilmesi gerekiyor ama acil değil, e-posta yeter. P3 bilgi — tekrarlanan hata kaydı için günlük rapor. Bu seviyelendirme uyarı yorgunluğunu önler.

Test ve Sahiplik
Her akış yayına alınmadan önce hata senaryoları test edilir. Veri kaynağı yoksa ne olur, alanlar boşsa ne olur, beklenmeyen format gelirse ne olur. Bu testler yapılmadan canlıya alınan akışlar ilk üç ayda sürpriz hatalarla durdurulur. Test disiplini erken yatırımdır ama uzun vadede çok zaman kazandırır.
Her akışın bir sahibi olmalıdır. Sahip akışın yöneticisidir; hata durumunda bildirim ona gider, müdahaleyi o yapar veya başkasına devreder. Sahibi olmayan akışlar yetim kalır; hata verdiğinde kimse fark etmez, etse de kim baktıracağını bilmez.
Sürekli İyileştirme
Hata izleme statik bir kurulum değildir. Aylık olarak hata log raporları gözden geçirilir, tekrar eden hatalar için akış güncellenir, yeni hata kategorileri eklenir. Bu döngü otomasyon programının zamanla daha sağlam hale gelmesini sağlar.
İyi tasarlanmış hata izleme akışların güvenilirliğini büyük ölçüde artırır; otomasyon kullanıcıları sistem sessizce çürümeden çalışmaya devam ettiğinden emin olurlar. Power Automate eğitimi bu disiplinin pratik kurulumunu detaylı işler.
Sıkça Sorulan Sorular
Run History 30 günden eski kayıtları korur mu?
Hayır, Power Automate Run History 30 günle sınırlıdır. Eski hata bilgilerini saklamak istiyorsanız Catch bloğunda merkezi log tablosuna yazmak zorunludur.
Configure Run After yerine try/catch programlaması var mı?
Power Automate'te programatik try/catch yok; Scope + Configure Run After kombinasyonu bunun yerine kullanılır. Birlikte try/catch desenini taklit eder.
Hata log tablosu Dataverse mi SharePoint mi olmalı?
Az miktarda log için SharePoint yeterlidir. Çok fazla hata kaydı veya analitik gerekiyorsa Dataverse daha uygundur. Premium lisans varsa Dataverse tercih edilir.
Retry policy'i değiştirebilir miyim?
Çoğu connector'da Settings menüsünden retry sayısı ve aralığı ayarlanır. Default genelde uygundur ama özel ihtiyaçlar için değiştirilebilir.
Aynı hata tekrar tekrar gelirse spam'a dönüşür mü?
Evet, uyarı eşiği koymadan tekrar eden hata yüzlerce bildirim üretebilir. Akıllı uyarı yapısı aynı hatanın belirli süre içinde sadece bir kez bildirildiği şekilde tasarlanır.
Akış sahibi ayrıldığında ne olur?
Akış otomatik olarak başkasına devredilmez. Sahibini takip eden bir kayıt tutmak ve ayrılma sürecinde devir yapmak yönetişim sorumluluğudur.



