POWER AUTOMATE İLE İŞ AKIŞI TEMELLERİ: ONAY, BİLDİRİM VE OTOMASYON MANTIĞI

Kurumsal ekiplerde “bir işi otomatikleştirelim” cümlesi, çoğu zaman küçük bir ihtiyaçla başlar ama hızla süreç tasarımına, onay zincirlerine ve ölçülebilir işletim kalitesine uzanır. Power Automate, bu yolculuğu düşük kod yaklaşımıyla hızlandırırken, doğru kurgulanmadığında beklenmedik gecikmeler, yanlış bildirimler veya yönetilemeyen akış spagettisine de kapı aralayabilir.

Bu makalede Power Automate iş akışı temellerini, üç ana eksen üzerinden ele alıyoruz: onay süreçleri, bildirim mekanikleri ve otomasyon mantığının omurgası olan tetikleyici–aksiyon–koşul modelinin doğru kullanımı. Hedefimiz, ilk akışınızı “çalışır” hale getirmekten öte; sürdürülebilir, izlenebilir ve kurumsal standarda yakın bir yaklaşım sunmak.

Okurken, akışların neden bazen “çalışıyor ama güven vermiyor” hissi yarattığını, hangi noktalarda tasarım kararlarının kritik olduğunu ve gerçekçi örneklerle hangi adımların tekrarlanabilir bir şablona dönüştürülebileceğini göreceksiniz. Son bölümde, daha derin pratik için Power Automate eğitimi sayfasına da yönlendirme bulacaksınız.

Power Automate Mantığı: Tetikleyici, Aksiyon, Koşul

Akışın iskeleti: Trigger → Actions → Outcomes

Power Automate’in en yalın modeli şudur: bir tetikleyici (trigger) bir olayı yakalar, ardından aksiyonlar çalışır ve sonuç bir koşula göre dallanır. Bu yapı basit görünür; ancak işin kurumsal tarafında, her bir adımın “girdi–çıktı sözleşmesi” net olmalıdır. Aksi halde akış, küçük veri farklılıklarında kırılabilir veya yanlış kişiye yanlış mesaj atabilir.

Tetikleyici seçerken, “ne zaman” ve “hangi veriyle” sorularına cevap verin. E-posta geldiğinde mi, bir SharePoint öğesi oluşturulduğunda mı, Teams’te bir form gönderildiğinde mi? Aksiyonlarda ise “hangi sistemde ne değişiyor” sorusu önemlidir. Dallanma (Condition / Switch) ile de karar noktalarını tanımlarsınız.

Connector yaklaşımı ve veri akışı

Birçok senaryoda, akışın gücü connector ekosisteminden gelir: Microsoft 365, SharePoint, Teams, Outlook, Dataverse, SQL, HTTP ve daha fazlası. Burada kritik olan, connector’ı “veriye erişim kapısı” olarak görmek ve yetkilendirme, hata toleransı ve performans gibi boyutları tasarımın parçası yapmaktır.

Örneğin, bir liste öğesinden gelen alan adları her zaman beklediğiniz gibi gelmeyebilir; bazen boş döner, bazen farklı tipte gelir. Bu noktada coalesce gibi ifadelerle varsayılan değer kullanmak, akış stabilitesini artırır.

Temel ifadeler (expressions) ile sağlamlaştırma

Düşük kod yaklaşımı, mantık yazmayı tamamen ortadan kaldırmaz; tersine, küçük ifadelerle büyük dayanıklılık sağlar. Aşağıdaki örnekler, koşul kurarken veya mesaj üretirken sık kullanılan gerçekçi kalıplardır.

// Boş gelme ihtimali olan alanları güvenli okumak
coalesce(triggerBody()?['RequesterEmail'], triggerOutputs()?['headers']?['x-ms-user-email'], 'unknown@company.com')

// Onay sonucuna göre kısa bir durum etiketi üretmek
if(equals(outputs('Start_and_wait_for_an_approval')?['body/outcome'],'Approve'),'Onaylandı','Reddedildi')

// Tarihi kullanıcı dostu formatlamak (ISO'dan gün/ay/yıl)
formatDateTime(utcNow(),'dd.MM.yyyy')

Onay Akışları: Basit Onaydan Kurumsal Zincire

Onay türünü seçmek: Tek kişi mi, grup mu?

Onay akışları, Power Automate’in en çok değer ürettiği alanlardan biridir. “Start and wait for an approval” aksiyonu ile tek onaylayıcıya, çoklu onaylayıcıya veya sıralı (sequential) onay senaryolarına gidebilirsiniz. Burada ilk tasarım kararı şudur: Onay “herhangi biri” tarafından mı, yoksa “hepsi” tarafından mı verilmeli? Bu karar, hem iş kuralını hem de süre yönetimini değiştirir.

Kurumsal senaryolarda sık görülen yaklaşım: belli tutarın altındaki talepler için tek onay, üstünde ise iki aşamalı onay. Bu ayrımı Condition ile yapıp, her dalda farklı onay kurgusu kullanabilirsiniz. Böylece akış, iş kuralını doğrudan modellemiş olur.

SLA ve zaman aşımı: Akışın takılı kalmasını engellemek

Onay adımlarının en büyük riski, akışın “beklemede” kalmasıdır. Onaylayıcı tatile çıkar, e-posta kaybolur, Teams bildirimi görülmez… Bu yüzden zaman aşımı (timeout) ve eskalasyon (escalation) tasarımı kritiktir. Power Automate’te adım seviyesinde timeout ayarlayabilir, zaman aşıldığında alternatif bir dal çalıştırabilirsiniz.

Pratik bir model: 24 saat içinde yanıt yoksa hatırlatma, 48 saatte yöneticiyi bilgilendirme ve 72 saatte otomatik iptal. Bu, “süreç yürümüyor” problemini yönetişim seviyesinde azaltır.

Onay çıktısını doğru kaydetmek: audit izi

Onay sonucu sadece “Approve/Reject” değildir. Kim onayladı, ne zaman, hangi yorumla? Kurumsal denetim için bu bilgileri kayıt altına almak gerekir. Genellikle SharePoint listesi, Dataverse tablosu veya SQL üzerinde “ApprovalLog” gibi bir yapı tercih edilir. Burada audit izi kavramı önemlidir: kararın bağlamını kaybetmeden saklamak.

Bildirim Akışları: Doğru Mesaj, Doğru Kanal, Doğru Zaman

Bildirim kanalı seçimi: E-posta, Teams, mobil push

Bildirim, otomasyonun “insanla temas ettiği” noktadır; bu yüzden tasarım hataları hızlıca güven kaybına dönüşür. E-posta, Teams mesajı, adaptif kart, mobil bildirim… Kanal seçerken ekibin günlük çalışma alışkanlıklerini dikkate alın. Örneğin, operasyon ekipleri Teams’te hızlı aksiyon alırken, satınalma veya finans ekipleri e-postada arşivlenebilirliği tercih edebilir.

İyi bir pratik: kritik durumlar için iki kanal kullanmak (Teams + e-posta) ama bunu kontrollü yapmak. Aksi halde kullanıcılar bildirim bombardımanına uğrar ve önemli mesajlar görünmez olur.

Mesaj içeriği: bağlam, eylem ve izlenebilirlik

Bir bildirim “bilgi” vermekle kalmamalı, eylemi kolaylaştırmalıdır. Mesajda şu üç öğeyi hedefleyin: bağlam (ne oldu), eylem (ne yapılmalı) ve izlenebilirlik (nereden takip edilir). Örneğin: “Talep #1842 onayınızı bekliyor” tek başına yeterli değildir; talep sahibi, tutar, tarih ve doğrudan kayıt linki gibi bilgiler eklenmelidir.

Teams tarafında adaptif kart (Adaptive Card) kullanmak, kullanıcı deneyimini belirgin şekilde iyileştirir. Kart içinde onay/ret butonları, detay linki ve kısa özet gösterebilirsiniz. Bu yaklaşım, “mesaj geldi ama ne yapacağım” belirsizliğini azaltır.

Bildirim gürültüsünü azaltma: koşullu ve özet akış

Her olayda bildirim göndermek yerine, koşullu bildirim ve özet (digest) yaklaşımı kullanın. Örneğin, aynı kişi gün içinde 10 talep girdiyse, tek tek 10 bildirim yerine gün sonu özeti daha verimli olabilir. Bu model, özellikle yüksek hacimli süreçlerde kullanıcı memnuniyetini artırır.

Koşullar, Dallanma ve İstisna Yönetimi

Condition ve Switch ile karar noktalarını netleştirmek

Akışlarda koşul sayısı arttıkça, okunabilirlik düşer. Condition adımlarını “iş kuralı cümleleri” gibi adlandırın: “Tutar 50.000 üzeri mi?”, “Talep türü yazılım mı?”, “İstek sahibi dış kullanıcı mı?” gibi. Switch, özellikle “kategori” bazlı dallanmada daha temiz bir tasarım sunar.

Okunabilir bir akış, ekip içinde paylaşılabilir akış demektir. Bu da bakım maliyetini düşürür. Ayrıca değişiklik taleplerinde, doğru noktayı bulmak hızlanır.

Hata yönetimi: Scope, Configure run after ve loglama

Kurumsal otomasyonda “hata yoktur” varsayımı çalışmaz; ağ kesilir, yetki değişir, hedef sistem limit koyar. Bu nedenle Scope bloklarıyla adımları gruplayın ve “Configure run after” ile başarısızlık senaryolarını yönetin. Basit bir desen:

• Try (ana iş adımları)
• Catch (hata mesajını topla, logla, ilgili kişiye bildir)
• Finally (temizlik: durum güncelle, iz kaydı oluştur)

Loglama tarafında, en azından akış çalıştırma kimliği (run id), giriş parametreleri ve hata özeti saklanmalıdır. Bu, “neden olmadı?” sorusunu somutlaştırır.

Tekrarlama (retry) ve idempotency: aynı iş iki kez olmasın

Power Automate bazı aksiyonlarda otomatik retry yapabilir. Bu, geçici hatalarda faydalıdır; ancak aynı işlemin iki kez çalışması riskini de getirir. Örneğin, bir kayıt oluşturma aksiyonu retry ile tekrar çalışırsa çift kayıt oluşabilir. İdempotent tasarım için, benzersiz bir “iş anahtarı” üretip önce var mı kontrol etmek iyi bir yaklaşımdır.

Gerçekçi Örnek: Talep Onayı + Teams Bildirimi + Kayıt Güncelleme

Senaryo: satınalma talebi akışı

Örnek senaryomuzda bir SharePoint listesine yeni “Satınalma Talebi” öğesi eklendiğinde akış tetikleniyor. Tutar belirli eşiği aşarsa iki aşamalı onay çalışıyor, her adımda Teams’e mesaj gidiyor, sonuçlar listeye yazılıyor. Bu akış, birden fazla bileşeni aynı anda görmenizi sağlar: tetikleyici, koşul, onay, bildirim ve kayıt güncelleme.

Adım adım akış tasarımı

1. Trigger: “When an item is created” (SharePoint)
2. Initialize variable: threshold = 50000
3. Condition: “Tutar >= threshold”
4. Dal 1: İki aşamalı onay (finans + yönetici)
5. Dal 2: Tek aşamalı onay (ekip lideri)
6. Update item: durum, onaylayan, tarih, yorum
7. Teams mesajı: sonuç özeti + kayıt linki

Teams için adaptif kart örneği

Aşağıdaki örnek, Teams’e gönderilebilecek basit bir adaptif kart gövdesini gösterir. Değerleri dinamik alanlarla doldurabilir, ilgili liste kaydına link ekleyebilirsiniz.

{
  "type": "AdaptiveCard",
  "version": "1.4",
  "body": [
    { "type": "TextBlock", "size": "Large", "weight": "Bolder", "text": "Satınalma Talebi Onay Bekliyor" },
    { "type": "TextBlock", "text": "Talep No: 1842", "wrap": true },
    { "type": "TextBlock", "text": "Tutar: 62.500 TL", "wrap": true },
    { "type": "TextBlock", "text": "İstek Sahibi: A. Yılmaz", "wrap": true }
  ],
  "actions": [
    { "type": "Action.OpenUrl", "title": "Talebi İncele", "url": "https://contoso.sharepoint.com/sites/procurement/Lists/Requests/DispForm.aspx?ID=1842" }
  ]
}

Run History ve Operasyonel İzleme

Run geçmişi okumak: nerede yavaşlıyor, nerede kırılıyor?

Akış yayına alındıktan sonra asıl iş başlar: izleme. Run history, adım adım hangi verinin geçtiğini ve hangi aksiyonun ne kadar sürdüğünü görmenizi sağlar. Gecikmeler genellikle dış sistem çağrılarında, onay bekleme adımlarında veya büyük veri dönüşümlerinde ortaya çıkar.

İyi bir pratik: kritik akışlar için belirli periyotlarda run history örneklemesi yapmak ve hata örüntülerini sınıflandırmak. Böylece “tekil hata” ile “sistematik problem” ayrımını kolayca yaparsınız.

Uyarı ve raporlama: yönetişim için görünürlük

Kurumsal seviyede, “kaç akış çalışıyor”dan çok “kaç akış güvenilir” sorusu önemlidir. Belirli bir hata oranının üzerinde uyarı üretmek, SLA ihlali olan akışları listelemek veya belirli connector hatalarını raporlamak, yönetişimin temel parçalarıdır. Bu noktada, log kayıtlarını merkezi bir alana (Dataverse/SQL) aktarmak ve Power BI ile izlemek yaygın bir yaklaşımdır.

Güvenlik, Yetkilendirme ve Governance Temelleri

Bağlantılar (connections) ve kimlik: kimin adına çalışıyor?

Akış, hangi kimlikle çalışıyor? Power Automate’te bağlantılar, kişisel hesapla kurulursa risk oluşabilir: kişi işten ayrılır, parola değişir, MFA policy güncellenir; akış etkilenir. Kurumsal yaklaşımlarda servis hesabı veya yönetilen bağlantı stratejisi tercih edilir. Buradaki amaç, akışın sürekliliğini kişilere bağımlı olmadan sağlamak.

DLP ve ortam (environment) kurgusu

Data Loss Prevention (DLP) politikaları, connector’ların birlikte kullanımını sınırlandırarak veri sızıntısı riskini azaltır. Örneğin, iş verisini kişisel depolama connector’larına taşıyan bir akışın engellenmesi, kurumsal güvenlik için kritiktir. Ayrıca ortam (dev/test/prod) ayrımı, hem kaliteyi hem de değişiklik yönetimini iyileştirir.

Sürdürülebilir tasarım ilkeleri

İyi bir otomasyon sadece “çalışan” otomasyon değildir; bakımı kolay, anlaşılır ve ölçeklenebilir olmalıdır. Aşağıdaki prensipler, uzun vadede maliyeti düşürür:

• İsimlendirme standardı: Trigger ve kritik aksiyonlar iş kuralını anlatmalı.
• Tek sorumluluk: Akış, mümkünse tek süreç amacı taşımalı; devasa mega-akışlardan kaçının.
• Merkezi konfigürasyon: Eşik değerler, e-posta listeleri gibi parametreleri değişken/konfig tablosunda tutun.
• Test edilebilirlik: Örnek veriyle akışı doğrulayın, negatif senaryoları da çalıştırın.

İlk Akışınızı Kurarken Sık Yapılan Hatalar

Yanlış tetikleyici: gereksiz çalıştırmalar ve maliyet

Çok sık tetiklenen bir trigger seçimi, gereksiz çalıştırmalara ve performans problemlerine neden olabilir. Örneğin, “When an item is modified” gibi tetikleyiciler, kontrolsüz bırakılırsa döngüye girebilir (akış güncelliyor, güncelleme tekrar tetikliyor). Bu riski önlemek için, belirli alan değişikliklerini kontrol eden koşullar veya “trigger conditions” kullanmak gerekir.

Veriyi dönüştürmeden kullanmak: tip uyuşmazlıkları

Sayısal alanı metin gibi ele almak, tarih formatını yanlış yorumlamak veya boş değerleri hesaba katmamak, en sık görülen problemlerdendir. Basit dönüşümler (int, float, formatDateTime) ve güvenli okuma (coalesce) ile akışın kırılma ihtimalini düşürürsünüz.

Bildirim içeriğini ihmal etmek: kullanıcı güveni

Bildirimin eksik bağlam sunması, kullanıcıların akışı önemsememesine yol açar. Kısa ama tamamlayıcı bir özet, link ve sorumluluk çağrısı, “bu mesaj neydi?” sorusunu ortadan kaldırır. Ayrıca gereksiz bildirimleri azaltmak, otomasyona olan güveni artırır.

Öğrenme Yol Haritası: Basitten İleri Seviyeye

Minimum uygulanabilir akıştan şablona

Başlangıçta, minimum uygulanabilir akış (MVP) yaklaşımı doğrudur: tek tetikleyici, tek onay, tek bildirim. Sonra bu yapıyı “şablon” haline getirin: hata yönetimi, loglama, zaman aşımı ve isimlendirme standardı ekleyin. Böylece yeni süreçler devreye alınırken, her seferinde sıfırdan tasarlamak yerine güvenilir bir temel kullanırsınız.

Kurumsal ölçekte ilerlemek

Akış sayısı arttıkça, yönetişim de önem kazanır: ortam ayrımı, DLP, connection stratejisi, erişim yetkileri, sahiplik devri ve dokümantasyon. Bu konular “sonradan eklenir” diye düşünülürse, büyüdükçe refactoring maliyeti katlanır. Bu yüzden temelde doğru alışkanlıklar edinmek gerekir.

Derinleşmek için pratik kaynak

Onay, bildirim ve otomasyon mantığını oturttuktan sonra, gerçek hayatta en çok değer üreten alanlar genellikle entegrasyon ve standartlaşmadır: Dataverse/SQL ile kayıt yönetimi, HTTP ile servis çağrıları, adaptif kartlarla kullanıcı deneyimi, ve yönetim politikaları. Bu yolculukta daha sistematik ilerlemek isterseniz Power Automate eğitimi içeriği, uygulamalı senaryolarla iyi bir sonraki adım olabilir.