POWER AUTOMATE İŞ AKIŞI TEMELLERİ

Bir kurumsal çalışan günde ortalama 40-60 dakikasını tekrarlayan dijital görevlere harcıyor: e-postayı SharePoint'e taşıma, form verisini Excel'e işleme, onay isteğini yöneticisine iletme. Bu 40 dakika ayda 14-20 saate çıkıyor. Power Automate işte bu zaman emici döngüleri otomatik akışa çevirmek için.

İlk akışı yazmanın zorluğu değil; doğru akışı yazmanın zorluğu önemli. Yanlış kurulmuş otomasyon, manuel işten daha fazla soruna yol açıyor. Power Automate'in temellerini doğru oturtmak, ileride çıkacak hataların büyük kısmını önlüyor.

Trigger: Akışı Başlatan Olay

Her akış bir trigger ile başlar — akışı başlatan olay. Power Automate üç tip trigger sunar:

• Otomatik (Automated): Bir olay olduğunda akış kendiliğinden başlar. "Yeni e-posta geldi", "SharePoint listesine kayıt eklendi", "Onay yanıtı verildi".
• Anlık (Instant): Kullanıcı bir butona basınca veya manuel tetikleyince. Power Apps içinden çağrılan akışlar, mobil cihazdan tetiklenen akışlar.
• Zamanlanmış (Scheduled): Belirli aralıklarla otomatik. "Her gün saat 09:00", "Her Pazartesi sabah".

Doğru trigger seçimi akışın temelini etkiliyor. "Her dakika çalışsın" gibi bir scheduled trigger gereksiz yere kaynak yiyor; bunun yerine olay tabanlı trigger çoğu zaman daha verimli.

Connector Mantığı

Power Automate'in gücü 700+ connector ile geliyor. Microsoft 365 servisleri (Outlook, SharePoint, Teams, OneDrive), üçüncü taraf uygulamalar (Salesforce, Slack, Google Workspace), veritabanları (SQL Server, Dataverse), web API'ları.

Connector tipleri ücret açısından üç gruba ayrılıyor:

• Standard: Microsoft 365 lisansı ile dahil. Office, SharePoint, Outlook, Teams.
• Premium: Ek lisans gerektiren. Dataverse, SQL Server, HTTP, üçüncü taraf SaaS.
• Custom: Kendi yazdığınız connector'lar.

Premium connector kullanan akışlar için her kullanıcının Power Automate Premium lisansı olması gerekiyor. Bu maliyet planı kurarken hesaba katılmalı; yoksa akış prototip aşamasında çalışıyor, üretim ortamında lisans hatasıyla duruyor.

Kontrol Akışı

Akışlar lineer değil; koşullar, döngüler, paralel kollar var. Temel kontrol yapıları:

• Condition: Eğer-değilse mantığı. "Tutar 10 binin üstüyse yöneticiye onaya gönder; altındaysa direkt işle."
• Switch: Çoklu seçenek. Departmana göre farklı onay yolu, talep tipine göre farklı akış.
• Apply to each: Liste üzerinde döngü. Excel'deki her satır için ayrı işlem.
• Do until: Koşul sağlanana kadar tekrar. Genelde polling senaryolarında.
• Parallel branch: Eş zamanlı paralel kollar. Aynı anda hem e-posta gönder hem Teams mesajı at.

İyi tasarlanmış akışlarda kontrol yapıları sade kalır; iç içe karmaşık koşullar yerine alt akış olarak parçalama tercih edilir.

Değişken Kullanımı

Akış içinde değer saklamak, hesaplamak, manipüle etmek için değişkenler:

• Initialize variable: yeni değişken tanımla
• Set variable: değer ata (override)
• Increment / Decrement variable: sayısal artır/azalt
• Append to string/array variable: ekleme yap

Tipik kullanım: bir liste üzerinde dönüp her başarılı işlemden sonra sayaç artırmak, sonunda "X kayıt başarıyla işlendi" raporu üretmek.

Önemli detay: değişken adı netleştirici olmalı. "var1" değil "BasariliIslenenKayitSayisi" gibi. Daha ileri ayrıntılar Power Automate resmi belgelerinde ele alınır. Akış karmaşıklaştıkça bu isimlendirme bakım kolaylığını dramatik etkiler.

Hata Yönetimi

Akış üretim ortamında çalışmaya başlayınca beklenmedik durumlar çıkar: network hatası, permission eksikliği, format uyumsuzluğu, API timeout. Her adımın "Configure run after" ayarı bu durumları yönetir.

Üç seçenek var:

• Is successful: Önceki adım başarılıysa çalıştır (varsayılan)
• Has failed: Önceki adım başarısızsa çalıştır (error handling kolu)
• Is skipped / Has timed out: Atlandı/zaman aşımı durumunda

Pratik bir hata yönetimi şablonu: ana iş Scope bloğunda, hata durumu için ayrı bir "Catch" Scope bloğu — Configure run after = Has failed. Catch bloğunda Teams'e bildirim, hata kaydı, geri dönüş aksiyonu. Bu yapı try-catch programlama yapısına yakın.

Idempotency: Aynı İşi İki Kez Yapmamak

Akışlar bazen aynı tetik için iki kez çalışabilir: webhook duplicate'i, kullanıcı butona iki kez basması, hata sonrası retry. Bu durumlarda akışın aynı işi iki kez yapmaması — idempotent olması — kritik.

Pratik bir idempotency uygulaması: her tetik için unique bir anahtar (örnek "OrderID + ProcessStep") oluşturmak, akışın başında SharePoint listesi veya Dataverse tablosuna bu anahtarı kontrol etmek. Var ise akış terminate, yok ise işle ve anahtarı kaydet.

Bu disiplin küçük akışlarda gereksiz görünür ama kritik iş süreçlerinde (ödeme, fatura, stok hareketi) zorunlu. İki kez ödenmiş fatura sorununu önler.

Sık Yapılan Yanlışlar

Power Automate sahada en sık şu hatalarla karşılaşıyor:

• Her olay için ayrı akış yazmak (5 benzer akış yerine 1 parametreli akış)
• "Apply to each" içinde Apply to each (iç içe döngü) — performans katlanıyor
• Hata yönetimi olmadan üretime almak — bir hata akışı durdurup tıkanma yaratıyor
• Test ortamında çalıştırılmayan akışın doğrudan üretime alınması
• Trigger condition kullanmamak — gereksiz tetiklenmeler kaynak yiyor
• Lisans maliyetini hesaba katmamak — premium connector ile prototip yapıp üretimde takılma

Bu yanlışların hepsi başlangıç döneminde yaygın. Birkaç akış çöktükten sonra disiplin oturuyor. Power Automate'i sistematik öğrenmek için Power Automate eğitim programı trigger seçimi, kontrol akışı, hata yönetimi ve onay süreçlerini uygulamalı senaryolarla ele alıyor.

Test ve Yayınlama

Üretime almadan önce her akışın test edilmesi şart. Test pratikleri:

• Manuel trigger ile farklı senaryolar — başarılı, hatalı, boş veri
• Edge case'ler — çok büyük veri, boş alan, özel karakter
• Permission senaryoları — yetkisi olmayan kullanıcı tetiklerse ne oluyor
• Hata yönetiminin gerçekten çalışıp çalışmadığı (kasten hata yarat)
• Performance — büyük listede süre nasıl, timeout riski var mı

Test ortamı ayrıysa daha iyi; üretim verisi üzerinde test etmek riskli. Microsoft 365 admin merkezi çoğu kurumda Dev/Test ortamı sunuyor. Üretim öncesi mutlaka kullanılmalı.