Power Automate İle Onay Süreci Tasarımı

Satın alma tarafında tıkanan yer çoğu şirkette aynıdır: Talep e-postayla gelir, biri “tamam” der, diğeri görmez, üçüncü kişi bütçe limitini sorar… Birkaç tur sonra kimse “en güncel onay kimde?” sorusuna net cevap veremez. Bu noktada sorun satın alma değil; iz kaybı ve standart eksikliğidir.

Power Automate, bu karmaşayı “tek bir akış” haline getirerek toparlar: Talep kimden geldi, hangi aşamada, kimde bekliyor, ne zaman onaylandı, reddedildiyse gerekçesi ne… Hepsi kayıt altındadır. Bu yazıda, gerçek hayatta işe yarayan basit ama sağlam bir satın alma onay kurgusunu adım adım anlatıyoruz.

 

Neden Power Automate Onay Akışı Satın Almada İyi Çalışır?

Satın alma, küçük ekiplerde bile çok kişili bir süreçtir: Talebi açan kişi, departman yöneticisi, bütçe sahibi/finans, bazen IT veya hukuk… E-posta ve Excel ile yürüyünce iki şey olur:

Birincisi, sürecin “tek doğru kaydı” olmaz. İkincisi, herkes kendi yöntemini üretir ve standart bozulur.

Power Automate ile süreç şeffaflaşır ve tek bir doğrultuda akar. Kullanıcı tarafında kazanım daha nettir: Talep açmak zor değilse, onay Teams’te tek ekranda görünüyorsa, reddedildiyse sebebi netse… İnsanlar süreci “sevmese bile” kullanır. Çünkü işini kolaylaştırır.

 

Akışa Başlamadan Önce 1 Dakikalık Gerçeklik Testi

Onay akışı tasarlamadan önce şu soruları netleştirin. Bu adım atlanırsa, en iyi otomasyon bile “kim neyi onaylıyor?” tartışmasına takılır.

• Talep hangi bilgilerle açılacak? (ürün/hizmet, adet, tahmini tutar, gerekçe, ihtiyaç tarihi, teklif/dosya ekleri) 
• Hangi kontroller zorunlu? (teklif var mı, tedarikçi belli mi, masraf merkezi doğru mu) 
• Kimler onaylıyor ve hangi sırayla? (yönetici → finans → limit üstü ise üst yönetim gibi) 
• Onaydan sonra ne olacak? (sipariş açma, kayıt kapama, ilgili ekibe bildirim vb.) 
• Reddedilince süreç nereye dönecek? (talep sahibine revizyon mu, tamamen kapanış mı) 

Amaç “daha çok kapı” koymak değil, doğru kapıları koymak. Gereksiz onay adımı, hızdan çalar ve sahiplenmeyi düşürür.

 

Veri Kaynağı Seçimi: SharePoint Mi, Dataverse Mü?

Sağlam bir onay sürecinin temeli şudur: Talep tek yerde dursun, herkes aynı kayda baksın, akış o kaydı güncellesin. Bunun için iki yaygın yaklaşım var.

SharePoint List hızlı başlamak için idealdir. Microsoft 365 ekosisteminde pratik şekilde “talep kaydı” oluşturur: tutar, departman, masraf merkezi, ekler, durum, onay geçmişi gibi alanları tek tabloda tutabilirsiniz.

Dataverse ise daha kurumsal ve ölçeklenebilir bir zemindir. Dynamics 365 kullanan yapılarda, yetkilendirme ve ilişkilendirme tarafında avantaj sağlar. Süreç büyüyecekse (çok departman, çok kural, daha sık raporlama) Dataverse tercih edilir.

Hangi seçeneği seçerseniz seçin, kritik nokta aynıdır: tek gerçek kaydı korumak.

 

Approval Tasarımı: Sıralı Mı Paralel Mi, Tek Kişi Mi Çoklu Mu?

Power Automate Approvals tarafında iki temel karar verirsiniz.

Sıralı onay, satın alma örneklerinde genellikle daha doğru çalışır. Önce yöneticinin görmesi, sonra finansın kontrol etmesi gibi. Çünkü roller birbirine bağımlıdır.

Paralel onay ise ancak kontroller gerçekten bağımsızsa verimlidir. Örneğin “Finans ve IT aynı anda kontrol etsin” gibi. Paralel tasarım doğru yerde zaman kazandırır; yanlış yerde ise “kim neyi bekliyor?” karmaşası üretir.

Bir de onay tipi kararı vardır: “İlk yanıt yeter” mi, “Herkes onaylasın” mı? Satın almada kritik kalemlerde genellikle herkes onaylasın yaklaşımı daha güvenlidir. Aksi halde biri görmeden süreç ilerleyebilir ve geri dönüş maliyeti büyür.

 

Tutar Limitleri Ve Koşullu Onaylar

Satın almanın gerçek hayat kuralı: 5.000 TL ile 500.000 TL aynı akıştan geçmez. Power Automate’in güçlü olduğu yer burasıdır: tutara göre onay zincirini otomatik değiştirirsiniz.

Örneğin belirli bir tutara kadar “yönetici + finans”, daha yukarıda “üst yönetim” eklenir. Burada önemli bir tasarım kararı var: Limitleri akışın içine sabitlemek yerine, mümkünse ayrı bir limit tablosu veya yönetilebilir bir yapıdan çekmek daha temizdir. Çünkü şirket büyüdükçe limitler değişir; akışın bakım maliyeti artmasın.

 

Bildirim Ve Kullanıcı Deneyimi

Onaylar en hızlı nerede görülür? Birçok şirkette cevap: Teams. Onayı Teams’e düşürmek, “mail kutusunda kaybolma” problemini azaltır. E-posta ise iyi bir yedektir; tek kanal olursa gecikme artabilir.

Burada küçük ama kritik bir detay var: Bildirim metnini kısa tutun. Onaylayan kişi 5 saniyede şunu anlamalı:

• Ne onaylıyor? 
• Tutar ne? 
• Hangi departman? 
• Teklif/dosya var mı?
  
  Detay için kayda tıklayıp açabilsin. Metin uzun olursa, onay “beklemede” kalır. 

 

Reddetme, Revizyon Ve Log

Her şey yolunda giderken akış kurmak kolay. Zor olan, pürüzleri yönetmek.

Reddedildiğinde ne olacak? Talep sahibine “revize et” olarak mı dönecek, yoksa kapanacak mı? Eksik bilgi varsa “düzelt ve tekrar gönder” gibi bir yol olacak mı? Onaylayan kişi yorum yazabilecek mi?

En pratik güvenlik adımı şudur: Reddetme gerekçesini zorunlu tutun. Gerekçe yoksa talep sahibi aynı şekilde tekrar gönderir, döngü uzar.

Ayrıca her adımın tarih/saat ve onaylayan bilgisiyle kaydı, hem izlenebilirlik sağlar hem de “kim geciktirdi?” tartışmasını azaltır. Akış hataları için de plan gerekir: bağlantı kopar, izinler değişir, onaylayıcı şirketten ayrılır… Hata durumunda talebi “hata” statüsüne çekmek ve ilgili kişilere bildirim göndermek üretimde büyük kurtarıcıdır.

 

Raporlama: Akış Gerçekten Hızlandırıyor Mu?

Onay akışını kurup bırakmak kolay; asıl değer ölçümle gelir. Şu sorulara yanıt verebiliyorsanız süreç gerçekten yönetilebilir hale gelir:

• Ortalama onay süresi kaç gün? 
• En çok hangi adımda bekliyor? 
• Hangi departmanda reddedilme oranı yüksek? 
• Hangi tutar aralıklarında süreç uzuyor? 

Power BI ile basit bir rapor bile büyük fark yaratır: talep sayısı, ortalama kapanış süresi, tutar dağılımı, aşama bazlı bekleme süresi… Power Automate + raporlama birleşince satın alma “görünmez bir e-posta trafiği” olmaktan çıkar, takip edilebilir bir operasyona dönüşür.

 

Satın alma onayı aslında “form doldurma” işi değil; hız ve güven dengesini doğru kurma işidir. Power Automate ile iyi tasarlanmış bir approval akışı; tutar limitlerine göre yönlendirme, Teams üzerinden hızlı onay, reddetme/revizyon mantığı ve kayıt/raporlama ile birlikte çalıştığında süreci belirgin şekilde sadeleştirir.

Başlangıç için en iyi yaklaşım: Süreci gereksiz büyütmeden, tek bir talep kaydı üzerinde (SharePoint ya da Dataverse) net roller ve net kurallarla başlamak. Sonra veriye bakarak iyileştirmek.

 

Sıkça Sorulan Sorular

Satın alma onayında SharePoint mi Dataverse mi seçmeliyim?

Hızlı başlamak ve Microsoft 365 içinde kalmak için SharePoint List iyi bir başlangıçtır. Süreç büyüyecek, çok kural/çok yetki yönetilecekse Dataverse daha ölçeklenebilir olur.

Sıralı mı paralel onay mı daha doğru?

Satın almada çoğu senaryoda sıralı onay daha nettir. Paralel onay, roller birbirinden bağımsızsa zaman kazandırır.

Limitleri akışın içine yazmak doğru mu?

Küçük süreçlerde olur; ama limitlerin değişmesi bekleniyorsa limitleri yönetilebilir bir tabloyla kontrol etmek bakım maliyetini düşürür.

Reddedilince süreç nasıl yönetilmeli?

Reddetme gerekçesini zorunlu tutmak ve talebi “revize” veya “kapalı” gibi net statülere bağlamak tekrar döngüsünü azaltır.