Power Automate ile Onay Süreçlerinin Tasarımı

Power Automate ile onay akışı kurmak birkaç dakikalık bir iştir; doğru tasarlanmış, istisnaları ele alan ve denetimde kanıt üreten bir onay süreci kurmak ise planlama gerektirir. Bu rehber satın alma, izin, belge yayını ve erişim yetkisi gibi kurumsal onay süreçlerinin tasarımında kullanılabilecek bir çerçeve sunar.

1. Onay matrisini yazın

Akış çizilmeden önce şu sorular cevaplanmalıdır: Kim onaylar? Hangi koşulda (tutar, kategori, departman) onaylayıcı değişir? Onaylar sıralı mı paralel mi? Red durumunda talep sahibine mi geri döner, kapanır mı? Örnek:

Koşul	1. adım	2. adım	3. adım
Tutar ≤ 10.000 TL	Birim yöneticisi	—	—
10.000 – 100.000 TL	Birim yöneticisi	Finans	—
> 100.000 TL	Birim yöneticisi	Finans	Genel müdür

Eşik değerleri ve onaylayıcılar akışın içine yazılmamalı, bir SharePoint listesinden okunmalıdır; böylece organizasyon değiştiğinde akış değiştirilmeden güncellenebilir.

2. Onay türünü doğru seçin

• Onayla/Reddet – herkes onaylamalı: Ortak karar gereken durumlar (ör. hem kalite hem üretim onayı).
• Onayla/Reddet – ilk yanıt: Aynı yetkiye sahip kişilerden biri yeterliyse (ör. finans ekibinden herhangi biri).
• Özel yanıtlar: “Onayla”, “Reddet”, “Bilgi iste” gibi seçenekler.
• Sıralı onaylar: Her adımın sonucu bir sonrakini tetikler; red durumunda akış durur.

3. İstisnaları tasarlayın

• Vekalet: Onaylayıcı izindeyse vekil kim? Vekalet listesi tutulmalı ve onay öncesi kontrol edilmelidir.
• Hatırlatma ve eskalasyon: 2 iş günü yanıt yoksa hatırlatma, 5 iş günü sonra üst yöneticiye yönlendirme.
• Talebin değişmesi veya geri çekilmesi: Bekleyen onay iptal edilmeli ve talep sahibine bildirim gönderilmelidir.
• Kendi talebini onaylama: Talep sahibi aynı zamanda onaylayıcıysa bir üst yöneticiye yönlendirilmelidir (görevler ayrılığı).

4. Kararı kayda yazın

Akış çalıştırma geçmişi platformda sınırlı süre saklanır ve denetim kanıtı olarak uygun değildir. Her onay adımının sonucu; onaylayan, karar, yorum ve zaman damgasıyla talep kaydına veya ayrı bir “onay geçmişi” listesine yazılmalıdır. Böylece raporlama yapılabilir ve denetimde “bu talebi kim, ne zaman onayladı?” sorusu tek tıkla cevaplanır.

5. Hata yönetimi

Kurumsal akışlarda hata sessiz kalmamalıdır. Önerilen yapı: ana işlemler bir “Try” kapsamında, hata durumunda çalışan bir “Catch” kapsamı (Configure run after: has failed / has timed out) ve bu kapsamda hata bildirimi ile hata kayıt listesine yazma. Geçici hatalar için eylem düzeyinde yeniden deneme ilkesi tanımlanır.

6. Sahiplik ve bağlantılar

Bir çalışanın kişisel hesabıyla oluşturulan akış, o kişi ayrıldığında veya parolası değiştiğinde durabilir. Kurumsal akışlar bir solution içinde, bağlantı referanslarıyla ve bir hizmet hesabı veya uygulama kimliğiyle çalıştırılmalı; birden fazla sahip tanımlanmalıdır. Ortam düzeyinde DLP ilkeleri iş verisinin onaysız bağlayıcılara aktarılmasını engeller.

7. Test senaryoları

1. Her eşik için onay zinciri doğru kişilere gidiyor mu?
2. Red, bilgi isteme ve geri çekme senaryoları çalışıyor mu?
3. Onaylayıcı vekalet listesindeyse vekile gidiyor mu?
4. Hatırlatma ve eskalasyon zamanları doğru mu?
5. Bağlantı hatası simüle edildiğinde hata bildirimi geliyor mu?

Lisans notu

SharePoint, Outlook, Teams ve Onaylar gibi standart bağlayıcılarla kurulan akışlar çoğu Microsoft 365 planında kullanılabilir. HTTP, SQL Server, Dataverse veya ERP bağlayıcıları gibi premium bağlayıcılar Power Automate Premium veya uygulama/akış bazlı lisans gerektirir; tasarım aşamasında doğrulanmalıdır.

Sık sorulan sorular

“Herkes onaylamalı” ile “ilk yanıt yeterli” arasındaki fark nedir?

Approvals eyleminde “Everyone must approve” seçeneği tüm onaylayıcıların onayını bekler, biri reddederse sonuç red olur. “First to respond” ise ilk yanıt veren kişinin kararını sonuç kabul eder; aynı role sahip birden fazla yetkiliden herhangi birinin yeterli olduğu durumlar içindir.

Onay 30 günden uzun beklerse ne olur?

Bulut akışlarının çalışma süresi sınırlıdır; uzun bekleyen onaylar için zaman aşımı tanımlanmalı, süre dolduğunda eskalasyon yapılmalı veya talep durum alanıyla yönetilip yeni bir akış tetiklenmelidir.

Onaylayıcı Teams kullanmıyorsa?

Approvals eylemi kararları Outlook e-postası, Teams ve Power Automate onay merkezi üzerinden kabul eder; kullanıcı istediği kanaldan yanıt verebilir.

Onay süreçlerinizi birlikte tasarlamak için Power Automate onay ve otomasyon ile form, talep ve onay sistemleri hizmetlerimize bakabilirsiniz.