Kurumsal Çok Aşamalı Onaylar İçin Web Uygulaması Oluşturma
Yönlendirme kuralları, roller, bildirimler ve denetim iziyle kurumsal çok aşamalı onaylar için bir web uygulamasını nasıl tasarlayıp yayına alacağınızı öğrenin.
Çok Aşamalı Onay Zincirleri Nedir (ve Neden Önemlidir)\n\nÇok aşamalı onay zinciri, bir isteğin ilerleyebilmesi için geçmesi gereken yapılandırılmış karar dizisidir. Rasgele e-postalara ve “tamam gibi görünüyor” mesajlarına dayanmak yerine, bir onay zinciri kararları tekrar edilebilir bir iş akışına dönüştürür; sahipliği, zaman damgalarını ve sonucu netleştirir.\n\nTemel seviyede, uygulamanız her istek için üç soruyu yanıtlıyor: \n\n- Kim onaylamalı?\n- Hangi sırada (veya hangi aşamada)?\n- Her karardan sonra ne olur?\n\n### Ardışık vs. paralel adımlar\n\nOnay zincirleri genellikle iki deseni birleştirir:\n\n- Ardışık onaylar: Adım B, Adım A onaylanana kadar başlayamaz. Örnek: bir purchasing (закупки) isteği önce takım liderini, sonra Finansı, sonra Satın Alma'yı gerektirebilir.\n- Paralel onaylar: Birden fazla onaylayıcı aynı anda inceleyebilir. Örnek: bir politika değişikliği Hukuk ve Güvenlik'in paralel onayını gerektirebilir ve ancak onaylandıklarında ilerleyebilir.\n\nİyi sistemler her ikisini de destekler; ayrıca “bunlardan herhangi biri onaylayabilir” ile “hepsinin onaylaması gerekir” gibi varyasyonlar da bulunur.\n\n### Tipik kurumsal kullanım örnekleri (genel örnekler)\n\nÇok aşamalı onaylar, izlenebilirliği olan kontrollü değişiklik gereken her yerde karşınıza çıkar:\n\n- Purchasing (закупки): tedarikçi seçimi, bütçe kontrolleri, satın alma onayı\n- Masraflar: yönetici onayı, finans doğrulaması, yüksek tutarlar için istisnalar\n- Erişim talepleri: yönetici onayı, sistem sahibi onayı, güvenlik incelemesi\n- Politika değişiklikleri: taslak, paydaş onayı, uyumluluk incelemesi, yayımlama\n\nİstek türü farklı olsa bile ihtiyaç aynıdır: kimin çevrimiçi olduğuna bağlı olmayan, tutarlı karar alma.\n\n### Kurumsalların onay zincirlerinden bekledikleri\n\nİyi tasarlanmış bir onay iş akışı sadece “daha fazla kontrol” değildir. Dört pratik hedefi dengelemelidir:\n\n- Hız: gereksiz gidip gelmeleri azaltmak ve beklemeleri ortadan kaldırmak\n- Kontrol: doğru kişilerin doğru şeyleri onayladığından emin olmak\n- Görünürlük: herkes durumu, sonraki adımı ve engelleri görebilmeli\n- Denetime hazır kayıtlar: kim, ne, ne zaman, karar ve gerekçe içeren eksiksiz bir denetim izi\n\n### Kaçınılması gereken yaygın tuzaklar\n\nOnay zincirleri daha çok süreç belirsizliğinden başarısız olur. Tekrarlayan problemlere dikkat edin:\n\n- Belirsiz sahiplik: kimse onaylayıcıyı bilmiyor, istekler takılır\n- Eksik denetim geçmişi: kararlar sohbet veya e-postada oluyor ve sonra kanıtlanamıyor\n- Çok fazla manuel adım: “bilgi amaçlı” incelemeler zorunlu onaylara dönüşür ve her şeyi yavaşlatır\n\nBu rehberin geri kalan kısmı, onayların iş için esnek, sistem açısından öngörülebilir ve gerektiğinde denetlenebilir kalmasını sağlayacak bir uygulama inşa etmeye odaklanır.\n\n## Kurumsal Onaylar için Gereksinimler Kontrol Listesi\n\nEkranları tasarlamadan veya bir iş akışı motoru seçmeden önce, gereksinimler üzerinde açıkça anlaşın. Kurumsal onay zincirleri birçok takımı etkiler ve küçük eksiklikler (ör. delege eksikliği) hızla operasyonel çözümlere dönüşür.\n\n### Erken dahil edilmesi gereken paydaşlar\n\nSistemi kullanacak veya inceleyecek kişileri isimlendirmekle başlayın:\n\n- İstek sahipleri (çalışanlar, yükleniciler, tedarikçiler)\n- Onaylayıcılar (yöneticiler, finans, hukuk, IT, güvenlik)\n- Yöneticiler (admin) (şablonları, yönlendirme kurallarını ve erişimi yöneten ops/destek)\n- Denetçiler/uyumluluk (iç denetim, dış düzenleyiciler)\n\nPratik bir ipucu: her gruptan en az bir kişiyle 45 dakikalık bir yürütme yapın; bir “tipik istek” ve bir “en kötü durum isteği” (escalation, yeniden atama, politika istisnası) üzerinden geçin.\n\n### Olmazsa olmaz iş akışı kabiliyetleri\n\nBu maddeleri test edilebilir ifadeler halinde yazın (her birinin çalıştığını ispatlayabilmelisiniz):\n\n- Eklentiler ve yapılandırılmış alanlarla istek gönderebilme\n- Onay/red, yorum ve her adım için karar kaydetme\n- Geçici delege (tatil) ve kalıcı yeniden atama (örgütsel değişiklikler)\n- Paralel onayları (ör. Finans ve Hukuk) ve ardışık adımları destekleme\n- Kim neyi görebilir sorusunu uygulama (istek sahibi görünürlüğü vs onaylayıcıya özel notlar)\n\n“İyi”nin neye benzediğine dair ilham arıyorsanız daha sonra bu gereksinimleri UX gereksinimlerine haritalayabilir ve /blog/approver-inbox-patterns benzeri referanslara bakabilirsiniz.\n\n### İşlevsel olmayan gereksinimler (kurumsal için ne gerekli)\n\nHedefleri tanımlayın, dilekleri değil:\n\n- Uptime ve RTO/RPO (ne kadar süre kapalı kalabilir, ne kadar veri kaybı kabul edilebilir)\n- Performans (ör. 10k bekleyen öğe için gelen kutusu 2 saniyenin altında yüklenmeli)\n- Veri saklama (istekler, yorumlar ve ekler ne kadar süre saklanacak)\n- Destek modeli (kim on-call, mesai saatleri, olaylar için SLA'lar)\n\n### Kısıtlar ve başarı metrikleri\n\nÖnceden kısıtları yakalayın: düzenlemeye tabi veri türleri, bölgesel depolama kuralları ve uzaktan çalışan bir ekip (mobil onaylar, saat dilimleri).\n\nSon olarak başarı metriklerinde uzlaşın: onay süresi (time-to-approve), % gecikmeli ve yeniden iş oranı (eksik bilgi nedeniyle kaç kez geri döndüğü). Bu metrikler önceliklendirmeyi yönlendirir ve yayılımı haklı çıkarmaya yardımcı olur.\n\n## Veri Modeli: İstekler, Adımlar, Kararlar ve Şablonlar\n\nNet bir veri modeli “gizemli onayları” önler—kimin neyi, ne zaman ve hangi kurallar altında onayladığını açıklayabilirsiniz. İş nesnesi olan Request ile süreç tanımı olan Template öğesini ayırarak başlayın.\n\n### Temel varlıklar\n\nRequest: isteği oluşturan kayıt. İstek sahibi kimliği, iş alanları (tutar, departman, tedarikçi, tarihler) ve destekleyici materyallere bağlantılar içerir.\n\nStep: zincirdeki bir aşamayı temsil eder. Adımlar genellikle gönderim zamanında bir Template'den oluşturulur, böylece her Request'in kendi değiştirilemez (immutable) sırası olur.\n\nApprover: genellikle bir adıma bağlı kullanıcı referansı (veya grup referansı). Dinamik yönlendirme destekleniyorsa, çözülen onaylayıcı(lar)ı ve onları üreten kuralı izlenebilirlik için saklayın.\n\nDecision: olay günlüğü: onay/red/iade, aktör, zaman damgası ve isteğe bağlı meta veriler (ör. delegated-by). Değişiklikleri denetleyebilmek için append-only (eklemeli) olarak modelleyin.\n\nAttachment: dosyaları (nesne depolamada) ve meta verileri saklar: dosya adı, boyut, içerik türü, checksum ve yükleyen.\n\n### Raporlamayı kolaylaştıran durumlar\n\nRaporlama için küçük, tutarlı bir Request durum seti kullanın:\n\n- Draft: düzenlenebilir, yönlendirilmemiş\n- Submitted: yönlendirme kurallarına kilitlenmiş, adımlar oluşturulmuş\n- In Review: en az bir bekleyen adım var\n- Approved: gerekli tüm adımlar tamamlandı\n- Rejected: reddedilme ile istek sona erdi\n- Canceled: istek sahibi/admin tarafından geri çekildi\n\n### Erken ihtiyaç duyacağınız adım tipleri\n\nYaygın adım semantiklerini destekleyin:\n\n- Tek onaylayıcı: bir kişi karar vermeli\n- Grup: grup üyelerinden herhangi biri karar verebilir\n- Kota (Quorum): N-of-M onayı gerekli\n- Koşullu: yalnızca bir koşul doğruysa dahil edilir (ör. tutar \u003e $10k)\n\n### Şablon versiyonlaması (sürpriz olmadan)\n\nWorkflow Template'i versionlu tutun. Bir şablon değiştiğinde, yeni Request'ler en son versiyonu kullanır, ancak akışta olan Request'ler oluşturuldukları versiyonu korur.\n\nHer Request'te template_id ve template_version saklayın ve gönderim anında kritik yönlendirme girdilerini (departman veya maliyet merkezi gibi) snapshot olarak alın.\n\n### Yorumlar ve dosyalar\n\nYorumları Request'e bağlı ayrı bir tablo olarak modelleyin (isteğe/isteğe adım/karara bağlı olarak da) böylece görünürlüğü kontrol edebilirsiniz (sadece istek sahibi, onaylayıcılar, adminler).\n\nDosyalar için: boyut limitleri uygulayın (ör. 25–100 MB), yüklemeleri zararlı yazılım için tarayın (asenkron karantina + serbest bırakma) ve veritabanınızda yalnızca referansları saklayın. Bu, çekirdek iş akışı verilerinin hızlı kalmasını ve depolamanın ölçeklenebilir olmasını sağlar.\n\n## Esnek Onay Yönlendirme Kurallarını Tasarlamak\n\nOnay yönlendirme kuralları kimin neyi onaylaması gerektiğini ve hangi sırada belirler. Kurumsal onay iş akışında püf noktası, katı politika ile gerçek dünya istisnaları arasında denge kurmaktır—her isteği özel bir iş akışına çevirmeden.\n\n### Net “sinyaller” ile başlayın\n\nÇoğu yönlendirme, isteğin birkaç alanından türetilebilir. Yaygın örnekler:\n\n- Tutar eşikleri (ör. $10k üzeri Finans ekler)\n- Departman veya maliyet merkezi (maliyet merkezi sahibine yönlendirir)\n- Lokasyon (yerel tüzel kişi veya bölgesel uyumluluk)\n- Risk seviyesi (yüksek riskli tedarikçiler için InfoSec/Hukuk eklenir)\n\nBunları hard-code etmek yerine yapılandırılabilir kurallar olarak değerlendirin, böylece adminler dağıtım olmadan politikaları güncelleyebilir.\n\n### Dinamik onaylayıcıları destekleyin\n\nStatik listeler çabuk bozulur. Bunun yerine dizin ve örgüt verilerine dayalı olarak çalışma zamanında onaylayıcıları çözün:\n\n- Yönetici zinciri (doğrudan yönetici, eşik üzerinde ise bir üstü)
SSS
What is a multi-step approval chain, and why do enterprises use it?
Çok aşamalı onay zinciri, bir isteğin tamamlanmadan önce bir veya daha fazla onay adımından geçmesi gereken tanımlı bir iş akışıdır.
Önemlidir çünkü tekrarlanabilirlik sağlar (her seferinde aynı kurallar), net sahiplik oluşturur (kimin neyi onayladığı) ve denetime hazır izlenebilirlik sunar (kim, ne zaman ve neden karar verdi).
When should approvals be sequential vs. parallel?
Sıralı onayları, sıra önemliyse kullanın (ör. yönetici onayı önce olmalı ki Finans inceleyebilsin).
Paralel onayları, birden fazla ekibin aynı anda inceleyebilmesi gerektiğinde kullanın (ör. Hukuk ve Güvenlik). Birleştirme kuralları tanımlayın, örneğin:
Tümünün onaylaması gerekir
Bunlardan herhangi biri onaylayabilir
N-of-M (kota)
What requirements should we gather before building an approval workflow?
En azından şu konularda uzlaşın:
Paydaşların kimler olduğu (istek sahipleri, onaylayıcılar, yöneticiler, denetçiler)
Her adımda hangi eylemlerin olduğu (onay/red/ değişiklik talebi, yorumlar)
Delege ve yeniden atama davranışı
Görünürlük kuralları (kim hangi alanları ve notları görebilir)
İşlevsel olmayan hedefler (çalışma süresi, performans, saklama)
Hızlı bir doğrulama yöntemi: her gruptan temsilcilerle “tipik” ve “en kötü durum” bir isteği birlikte gözden geçirin.
What are the key data model entities for enterprise approvals?
Pratik bir çekirdek model şunları içerir:
How should workflow template versioning work to avoid surprises?
Şablonları sürümleyin, böylece politika değişiklikleri geçmişi yeniden yazmaz:
Her isteğe template_id ve template_version ekleyin
Adım listesini gönderim anında oluşturup 'dondurun'
Şablon düzenlemeleri yalnızca yeni isteklere uygulanır
Admin konsolunda sürüm geçmişi ve geri alma yolu tutun
Bu, akıştaki isteklerin aniden farklı yönlendirilmesine engel olur.
How do we design flexible approval routing rules without hard-coding approvers?
Yönlendirme kurallarını yapılandırılabilir ve politika tabanlı tutun; yaygın sinyaller:
Tutar eşikleri
Departman/maliyet merkezi
Lokasyon/bağlı tüzel kişi
Risk seviyesi
Onaylayıcıları, kayıt sistemlerinden (directory, HRIS, ERP) çalıştırın ve hem çözülen onaylayıcıları hem de onları üreten kuralı saklayın (izlenebilirlik için). Statik listeler çabuk eskir.
What makes a workflow engine reliable for approvals?
İsteği açık bir durum makinesi olarak ele alın (ör. DRAFT → SUBMITTED → IN_REVIEW → APPROVED/REJECTED/CANCELED).
Gerçek koşullarda güvenilir kılmak için:
Geçişleri sunucu tarafında zorunlu kılın (izinler + doğrulama)
Karar eylemlerini idempotent yapın (çifte tıklamaya dayanıklı)
Hatırlatma/escalation işlerini arka plan görevleriyle çalıştırın
İş akışı mantığını UI ve entegrasyonlardan ayırın
What security and audit features are essential for enterprise approvals?
Yetkilendirme: RBAC ve isteğe özel kontroller (takım/maliyet merkezi/bölge bazlı erişim)
Veri koruma: TLS, dinlenme halinde şifreleme, secrets manager
Denetim izi: submit/view/decide/delegate gibi eklemeli olaylar, zaman damgası ve aktör kimliği ile
Ayrıca işlem uç noktalarını koruyun: rate limit, CSRF ve tek kullanımlık eylem tokenleri gibi önlemler alın.
How should the requester flow and approver inbox be designed?
Kararı hızlı almayı, ama bağlamı kaybetmemeyi hedefleyin:
Akıllı varsayılanlar ve satır içi doğrulama ile istek formu
Onaylayıcı gelen kutusunda öncelik/SLA vurgusu, güvenli filtreleme
İstek detay sayfasında özet, ekler ve etkinlik zaman çizelgesi
Reddetmeler için neden zorunlu kılın ve önceki adımda ne değiştiğini gösterin
Mobil için: katlanabilir bölümler, sabit özet ve erişilebilirlik gereksinimlerine uyum sağlayın.
How do we implement notifications, reminders, and escalations without spamming users?
Bildirimleri görev teslim sistemi gibi kurun, sadece mesaj göndermeyin:
E-posta + uygulama içi bildirim; istenirse sohbet araçlarına aynalayın
Gürültüyü azaltmak için batching/digest kullanın
Hatırlatmaları yalnızca öğe hâlâ bekliyorsa gönderin; saat dilimleri ve sessiz saatlere saygı gösterin
Yükseltme açık bir sahipliğe gidecek şekilde yapılandırılmalı (yönetici, yedek onaylayıcı veya operasyon kuyruğu)
Her bildirim eyleme çağırmalı: ne değişti, hangi eylem gerekli (ve ne zamana kadar) ve gibi doğrudan hedef gösterin.
Kurumsal Çok Aşamalı Onaylar İçin Web Uygulaması Oluşturma | Koder.ai
Finans/ERP'den maliyet merkezi sahibi
Proje sisteminden proje lideri\n\nÇözücüyü açık yapın: yalnızca son adı saklamayın; onaylayıcının nasıl seçildiğini saklayın (ör. “manager_of: user_123”).\n\n### Paralel adımlar ve birleştirme mantığı\n\nKurumsallar genellikle birden çok onayı aynı anda ister. Paralel adımları açık bir birleştirme davranışıyla modelleyin:\n\n- Tümünün onaylaması gerekir (ör. Finans ve Hukuk)
Bunlardan herhangi biri onaylayabilir (ör. birkaç bütçe sahibinden biri)
\nReddetme durumunda ne olacağına da karar verin: hemen durdurulsun mu yoksa “yeniden düzenle ve tekrar gönder” mü mümkün olsun.\n\n### Yükseltmeler ve istisnalar\n\nYükseltme kurallarını birinci sınıf politika olarak tanımlayın:\n\n- X saat/gün sonra hatırlatmalar\n- Süre aşımı durumda (overdue) yöneticilere veya yeniden atama kuyruğuna yükseltme\n- Kaçırılan SLA üzerine otomatik yükseltme\n\nİstisnaları önceden planlayın: ofis dışı durumlar, delege, yedek onaylayıcılar ve her yeniden yönlendirme için denetlenebilir bir gerekçe kaydedin.\n\n## İş Akışı Motoru: Adımları Güvenilir Şekilde Orkestre Etmek\n\nÇok aşamalı onay uygulamasının başarısı tek bir şeye bağlıdır: iş akışı motorunun istekleri öngörülebilir şekilde ilerletebilmesi—kullanıcılar iki kez tıklasa, entegrasyonlar gecikse ya da onaylayıcı ofis dışında olsa bile.\n\n### Kendi motorunuzu inşa etmek vs. bir kütüphane benimsemek\n\nOnay zincirleriniz büyük ölçüde doğrusal ise (Adım 1 → Adım 2 → Adım 3) ve birkaç koşullu dal varsa, basit bir dahili motor genellikle en hızlı yoldur. Veri modeline tam kontrol sağlarsınız, denetim olaylarını özelleştirebilirsiniz ve gereksiz kavramları sisteme çekmezsiniz.\n\nEğer karmaşık yönlendirme bekliyorsanız (paralel onaylar, dinamik adım ekleme, telafi eylemleri, uzun süren zamanlayıcılar, versiyonlanmış tanımlar), bir iş akışı kütüphanesi veya servisi benimsemek riski azaltabilir. Takas noktası operasyonel karmaşıklık ve onay kavramlarınızı kütüphanenin ilkelere eşleştirme gerekliliğidir.\n\nHızlıca çalışan bir dahili araç çıkarmanız gereken “çalışır bir iç araç hemen göndermeliyiz” aşamasındaysanız, Koder.ai gibi bir vibe-coding platformu uçtan uca akışı prototiplemek (istek formu → onaylayıcı gelen kutusu → denetim zaman çizelgesi) ve planlama modunda yönlendirme kurallarını yineleyerek gerçek bir React + Go + PostgreSQL kod tabanı üretip dışa aktarmanıza yardımcı olabilir.\n\n### Net bir durum makinesi tanımlayın\n\nHer isteği açık, doğrulanmış geçişleri olan bir durum makinesi olarak ele alın. Örnek: DRAFT → SUBMITTED → IN_REVIEW → APPROVED/REJECTED/CANCELED.\n\nHer geçişin kim tarafından yapılabileceği, gerekli alanlar ve hangi yan etkilerin izinli olduğu gibi kuralları olmalı. Geçiş doğrulamasını sunucu tarafında tutun ki UI kontrolleri atlayamasın.\n\n### Idempotency: düğmelere iki kez tıklanacağını varsayın\n\nOnaylayıcı eylemleri idempotent olmalı. Bir onaylayıcı "Approve" düğmesine iki kez tıklarsa (veya yavaş bir yanıtta yenilerse), API tekrarı tespit edip aynı sonucu döndürmeli.\n\nYaygın yaklaşımlar: eylem başına idempotency anahtarları kullanmak veya “her adım için her aktörün tek kararı” gibi benzersiz kısıtlar uygulamak.\n\n### Zamanlayıcılar ve yükseltmeler için arka plan işleri\n\nZamanlayıcılar (SLA hatırlatmaları, 48 saat sonra yükseltme, süresi geçenlerin otomatik iptali) arka plan işleriyle çalıştırılmalı; request/response kodunda değil. Bu, UI'nin duyarlı kalmasını sağlar ve trafik artışlarında bile zamanlayıcıların çalışmasını garanti eder.\n\n### İş akışı mantığını UI ve entegrasyonlardan ayırın\n\nYönlendirme, geçişler ve denetim olaylarını özel bir iş akışı modülü/servisinde tutun. UI "submit" veya "decide" çağrmalı, entegrasyonlar (SSO/HRIS/ERP) girdi sağlamalı—iş akışı kurallarını gömme. Bu ayrım değişikliği daha güvenli ve test etmeyi daha kolay kılar.\n\n## Güvenlik, Erişim Kontrolü ve Denetime Hazırlık\n\nKurumsal onaylar genellikle harcama, erişim veya politika istisnalarını engeller—bu yüzden güvenlik sonradan düşünülmemeli. İyi bir kural: her karar gerçek bir kişiye (veya sistem kimliğine) bağlanabilir, o özel istek için yetkili olmalı ve kanıtlanabilir şekilde kaydedilmelidir.\n\n### Kimlik doğrulama: kullanıcıyı kanıtlayın\n\nKimlikleri, deprovisioning'i ve parola politikalarını merkezi tutmak için SSO ile başlayın. Çoğu kurum SAML veya OIDC bekler, genellikle MFA ile birlikte.\n\nYüksek riskli eylemler (ör. nihai onay) için kısa ömürlü oturum politikaları, cihaz tabanlı "beni hatırla" mekanizmaları ve rol değiştiğinde yeniden kimlik doğrulama ekleyin.\n\n### Yetkilendirme: eylemi yapmaya izinleri kanıtlayın\n\nGeniş izinler için rol tabanlı erişim denetimi (RBAC) kullanın (Requester, Approver, Admin, Auditor) ve üzerine isteğe özel izinler koyun.\n\nÖrneğin bir onaylayıcı yalnızca kendi maliyet merkezindeki, bölgesindeki veya doğrudan raporlarının isteklerini görebilir. Her okuma ve yazma işleminde yetkileri sunucu tarafında uygulayın—özellikle "Approve", "Delegate" veya "Edit routing" gibi eylemler için.\n\n### Veri koruma: içerik ve sırları koruyun\n\nVerileri aktarımda TLS ile ve dinlenmede mümkünse yönetilen anahtarlarla şifreleyin. SSO sertifikaları ve API anahtarları gibi sırları bir secrets manager'da saklayın, sunucular arasında dağınık environment değişkenlerinde değil.\n\nNe logladığınıza dikkat edin; istek detayları hassas İK veya finansal veri içerebilir.\n\n### Denetime hazırlık: her kararı açıklanabilir yapın\n\nDenetçiler, kimin ne yaptığını, ne zaman ve nereden görmek ister.\n\nHer durum değişikliğini (gönderildi, görüntülendi, onaylandı/ret edildi, delege edildi) zaman damgası, aktör kimliği ve ilgili ID'lerle kaydedin. İzin verildiğinde IP ve cihaz bağlamını da yakalayın. Logların eklemeli ve tahrifata karşı belirgin olmasını sağlayın.\n\n### Kötüye kullanımı önleme: yaygın saldırıları engelleyin\n\nOnay eylemleri için hız sınırlaması uygulayın, CSRF'ye karşı koruyun ve e-posta ile gelen linkler veya tekrar oynatılan istekler yoluyla onay sahteciliğini önlemek için sunucu tarafından üretilen tek kullanımlık eylem tokenleri isteyin.\n\nToplu onaylar, hızlı ardışık kararlar veya alışılmadık coğrafyalar gibi şüpheli desenler için uyarılar ekleyin.\n\n## Kullanıcı Deneyimi: İstek Sahibi Akışı ve Onaylayıcı Gelen Kutusu\n\nKurumsal onaylar açıklık üzerinde başarır veya başarısız olur. İnsanlar neyi onayladıklarını (ve neden) hızlıca anlayamazsa, erteleyebilir, devredebilir veya varsayılan olarak reddedebilirler.\n\n### Tasarlanacak ana ekranlar\n\nİstek formu; istek sahibinin doğru bağlamı ilk kez vermesini sağlamalı. Akıllı varsayılanlar (departman, maliyet merkezi), satır içi doğrulama ve kısa bir "sonraki adım ne olacak" ipucu kullanın ki istek sahibi onay zincirinin karanlıkta kalmayacağını bilsin.\n\nOnaylayıcı gelen kutusu iki soruyu anında yanıtlamalı: şimdi ne benim dikkatimi gerektiriyor ve beklemem bir risk oluşturuyor mu. Öğeleri öncelik/SLA'ye göre gruplayın, hızlı filtreler ekleyin (takım, istek sahibi, tutar, sistem) ve yalnızca güvenli olduğunda toplu işlemleri etkinleştirin (ör. düşük riskli istekler).\n\nİstek detayı kararların verildiği yerdir. Üstte net bir özet (kim, ne, maliyet/etki, yürürlük tarihi), ardından destekleyici detaylar: ekler, bağlantılı kayıtlar ve etkinlik zaman çizelgesi olsun.\n\nAdmin builder (şablonlar ve yönlendirme için) politika gibi okunmalı, diyagram gibi değil. Düz anlaşılır kurallar, önizlemeler ("bu istek Finans → Hukuk'a yönlendirilir") ve değişiklik günlüğü kullanın.\n\n### Kararları kolay (ve güvenli) hale getirin\n\nSon adımdan bu yana ne değiştiğini vurgulayın: alan düzeyinde farklar, güncellenmiş ekler ve yeni yorumlar. Tek tıklamayla eylemler sağlayın (Approve / Reject / Request changes) ve reddetmeler için zorunlu bir gerekçe isteyin.\n\n### Aşırı bilgi yüklemeden şeffaflık\n\nGeçerli adımı, sonraki onaylayıcı grubunu (her zaman kişiyi değil) ve SLA zamanlayıcılarını gösterin. Basit bir ilerleme göstergesi "isteğim nerede" sorularını azaltır.\n\n### Mobil uyumlu ve erişilebilir\n\nMobilde hızlı onayları destekleyin, bağlamı koruyun: katlanabilir bölümler, sabit özet ve ek önizlemeleri.\n\nErişilebilirlik temelleri: tam klavye navigasyonu, görünür odak durumları, okunabilir kontrast ve durumlar ile düğmeler için ekran okuyucu etiketleri.\n\n## Bildirimler, Hatırlatmalar ve Yükseltmeler\n\nOnaylar, insanların haberi olmadığında sessizce başarısız olur. İyi bir bildirim sistemi çalışmayı gürültüye dönüştürmeden ilerletir ve kimlerin, ne zaman ve neden uyarıldığının net kaydını oluşturur.\n\n### Kanallar: kullanıcıları çalıştıkları yerde yakalayın\n\nÇoğu kurum en az e-posta ve uygulama içi bildirim ister. Şirketiniz sohbet araçlarını (ör. Slack veya Microsoft Teams) kullanıyorsa, bunları uygulama içi uyarıları aynalayan isteğe bağlı bir kanal olarak düşünün.\n\nAynı olayın aynı “görevi” oluşturduğundan emin olun; e-posta ya da sohbetle teslim edilse bile.\n\n### Spam yapmamak için akıllı zamanlama\n\nKüçük değişiklikler için her seferinde mesaj göndermek yerine etkinlikleri gruplayın:\n\n- Toplama (Batching): aynı istek için kısa bir pencerede (ör. 5–10 dakika) gelen birden çok güncellemeyi birleştirin\n- Özetler (Digests): izleyiciler veya bilgi amaçlı kişiler için günlük/haftalık özetler\n- Akıllı hatırlatmalar: onaylayıcı hâlâ harekete geçmediyse hatırlatma gönderin\n\nAyrıca sessiz saatlere, saat dilimlerine ve kullanıcı tercihine saygı gösterin. E-posta kapatmayı seçen bir onaylayıcı yine de uygulama içi kuyruğu açıkça görmelidir (örneğin, /approvals).\n\n### Mesaj içeriği: spesifik ve eyleme geçirilebilir olsun\n\nHer bildirim üç soruya cevap vermeli:\n\n1. Ne değişti? (Gönderildi, adım ilerledi, reddedildi, yorum eklendi.)\n2. Hangi eylem gerekli? (Approve/Reject/Request changes; hangi tarihe kadar.)\n3. Nereye gitmeliyim? Bir derin bağlantı ekleyin, örneğin /requests/123?tab=decision.\n\nOnaylayıcıların hızlıca öncelik vermesi için bildirimde istek başlığı, istek sahibi, tutar ve politika etiketi gibi temel bağlamı ekleyin.\n\n### Hatırlatma takvimi ve yükseltmeler\n\nVarsayılan bir takvim tanımlayın (ör. ilk hatırlatma 24 saat sonra, sonra her 48 saatte bir), ama şablon başına geçersiz kılmalara izin verin.\n\nYükseltmelerin açık bir sahipliği olmalı: yöneticinin rolüne, bir yedek onaylayıcıya veya bir operasyon kuyruğuna yükselebilir—"herkese" değil. Yükseltme olduğunda gerekçeyi ve zaman damgasını denetim izine kaydedin.\n\n### Şablonlar ve yerelleştirme\n\nBildirim şablonlarını merkezi yönetin (kanal başlığı/gövdesi), bunları versiyonlayın ve değişkenlere izin verin. Yerelleştirme için çevirileri şablonla birlikte saklayın ve eksik olduğunda varsayılan dile geri dönün.\n\nBu, "yarı çevrilmiş" mesajların önüne geçer ve uyumluluk ifadelerinin tutarlı kalmasını sağlar.\n\n## Kurumsal Sistemlerle Entegrasyonlar ve API'ler\n\nKurumsal onaylar nadiren tek bir uygulamada yaşar. Manuel tekrar girişini azaltmak (ve "diğer sistemi güncelledin mi?" sorununu ortadan kaldırmak) için entegrasyonları birinci sınıf özellik olarak tasarlayın.\n\n### Bağlanmanız muhtemel sistemler\n\nKuruluşunuzun zaten güvendiği doğruluk kaynaklarıyla başlayın:\n\n- İK dizini / kimlik sağlayıcı (yönetici ilişkileri, departmanlar, istihdam durumu için)
ERP / finans sistemi (maliyet merkezleri, bütçeler, tedarikçi kayıtları, satın alma emirleri için)
Ticketing (onayları olaylara/değişikliklere bağlamak ve operasyonel iz tutmak için)
Belge depolama (sözleşmeler, teklifler, politikalar, destekleyici dosyalar)
\nHepsini ilk günden bağlamasanız bile veri modelinizde ve izinlerde bunun için plan yapın (bkz. /security).\n\n### API ve webhook tasarımı\n\nTemel eylemler için stabil bir REST API (veya GraphQL) sağlayın: istek oluştur, durum al, kararları listele ve tam denetim izini alın.\n\nGiden otomasyon için webhook ekleyin ki diğer sistemler gerçek zamanda tepki verebilsin.\n\nÖnerilen olay türleri:\n\n- request.submitted\n- request.step_approved\n- request.step_rejected\n- request.completed\n\nWebhook'ları güvenilir yapın: olay ID'leri, zaman damgaları, geri denemelerle backoff ve imza doğrulama içersin.\n\n### Gelen entegrasyonlar: diğer araçlardan istek oluşturma\n\nBirçok ekip onayları kullandıkları yerden (ERP ekranları, ticket formları veya dahili portal) başlatmak ister. Servis-ara-servis kimlik doğrulamasını destekleyin ve dış sistemlerin şunları yapmasına izin verin:\n\n- bir şablondan istek oluşturma\n- meta veri ekleme (tutar, maliyet merkezi, tedarikçi)\n- orijinal kayda geri bağlantılar ekleme\n\n### Veri eşlemesi ve kimlik eşleştirme\n\nKimlik, başarısızlığın ortak nedenidir. Kanonik tanımlayıcıyı belirleyin (genelde çalışan ID'si) ve e-postaları takma adlar olarak eşleyin.\n\nKenar durumları yönetin: isim değişiklikleri, ID'si olmayan yükleniciler ve yinelenen e-postalar. Eşleştirme kararlarını adminlerin hızla çözebilmesi için loglayın ve admin raporlamada durumu gösterin (bkz. /pricing plan farklılıklarına göre entegrasyon farkları).\n\n## Operasyon için Admin Konsolu ve Raporlama\n\nKurumsal bir onay uygulamasının başarısı ikinci günden itibaren ölçülür: takımların şablonları ne kadar hızlı ayarlayabildiği, kuyrukları nasıl açık tuttuğu ve bir denetimde ne olduğunu ne kadar çabuk ispat ettiği.\n\nAdmin konsolu bir kontrol odası gibi hissettirmeli—güçlü ama güvenli.\n\n### Şablonlar, gruplar, politikalar ve SLA'lar yönetin\n\nAçık bir bilgi mimarisi ile başlayın:\n\n- İş akışı şablonları (örn. “Harcam a Onayı”, “Tedarikçi Onboarding”) sahipleri ve ne zaman kullanılacağı açıklaması ile\n- Onaylayıcı gruplar (Finance Ops, Legal Reviewers) bireyler değil, rollere ve lokasyonlara göre eşlenmeli\n- Politikalar ve SLA'lar (örn. “$50k üzeri için CFO adımı gerekli”, “Adım 2 iki iş gününde tamamlanmalı”)\n\nAdminler kazara düzenleme yapmamak için iş birimi, bölge ve şablon versiyonuna göre arama ve filtreleme yapabilmeli.\n\n### Güvenli düzenlemeler: taslak/yayınla, versiyonlama, geri alma\n\nŞablonları dağıtıma hazır konfigürasyon gibi ele alın:\n\n- Taslak vs yayımlanmış haller, etkilenecek istek tiplerini gösteren önizleme ile\n- Versiyon geçmişi ve yönlendirme kuralı gecikmeye neden olursa tek tıklamayla geri alma\n- Kural: akıştaki istekler orijinal versiyonlarını korur, yeni istekler en son yayımlananı kullanır\n\nBu operasyonel riski azaltır ama gerekli politika güncellemelerini yavaşlatmaz.\n\n### İzinler: adminler, süper adminler, denetçiler\n\nSorumlulukları ayırın:\n\n- Adminler atandıkları kapsam içinde şablonları ve grupları yönetir\n- Süper adminler küresel politikaları, saklama ve entegrasyonları değiştirir\n- Denetçiler loglara, dışa aktarımlara ve raporlara salt okunur erişim alır\n\nBunu kim neyi, ne zaman ve neden değiştirdiğini gösteren değiştirilemez bir etkinlik günlüğü ile eşleştirin.\n\n### Raporlama, dışa aktarımlar ve saklama\n\nPratik bir pano şunları vurgular:\n\n- Tıkanma noktaları (en uzun medyan süreye sahip adımlar)\n- Gecikmiş kuyruklar (takım, şablon, bölge bazında)\n- En popüler istek türleri ve reddetme nedenleri\n\nDışa aktarmalar ops için CSV ve ayrıca bir denetim paketi (istekler, kararlar, zaman damgaları, yorumlar, ek referansları) olarak sağlanmalı ve saklama pencereleri yapılandırılabilmeli.\n\nRaporlardan /admin/templates ve /admin/audit-log gibi yönetim ekranlarına bağlantı verin ki hızlı aksiyon alınabilsin.\n\n## Test, İzleme ve Hata Yönetimi\n\nKurumsal onaylar dağınık, gerçek dünya şekillerinde başarısız olur: insanlar rol değiştirir, sistemler zaman aşımına uğrar ve istekler dalgalar halinde gelir. Güvenilirliği bir özellik olarak ele alın.\n\n### Risklere uygun bir test stratejisi\n\nÖnce onay yönlendirme kuralları için hızlı birim testleriyle başlayın: bir istek sahibi, tutar, departman ve politika verildiğinde iş akışı her seferinde doğru zinciri seçiyor mu? Bu testleri tablo tabanlı tutun ki iş kuralları kolayca genişleyebilsin.\n\nSonra tam iş akışı motorunu egzersiz eden entegrasyon testleri ekleyin: bir istek oluşturun, adım adım ilerletin, kararları kaydedin ve nihai durumu (approved/rejected/canceled) ve denetim izini doğrulayın.\n\nGörünürlük için izin kontrollerini (kim onaylayabilir, delege edebilir veya görüntüleyebilir) test edin.\n\n### Simüle edilmesi gereken kenar durumları\n\nBirkaçı "geçmesi gereken" senaryolar olmalı:\n\n- Onaylayıcı isteğin ortasında işi bırakır (adım yeniden atama yoluyla rol, yönetici veya admin müdahalesi ile)\n- Çatışan kararlar (çift tıklama onayları, paralel adımlar veya yükseltmeden sonra gelen geç kararlar)\n- Şablon zaman içinde değiştiğinde (akıştaki isteklerin kendi template_version'larını kullanmaya devam ettiğini doğrulayın)\n\n### Yük testi ve operasyonel görünürlük\n\nGelen kutusu görünümünü ve bildirimleri ani gönderimler altında yük testinden geçirin, özellikle istekler büyük ekler içeriyorsa. Kuyruk derinliğini, adım başına işlem süresini ve en kötü durum onay gecikmesini ölçün.\n\nGözlemlenebilirlik için her durum geçişini bir korelasyon ID'si ile loglayın, “sıkışmış” iş akışları için metrikler yayınlayın ve asenkron çalışanlar arasında izleme (tracing) ekleyin.\n\nUyarılacak durumlar: artan yeniden denemeler, dead-letter kuyruğu büyümesi ve adım süresi beklenenden fazla olan istekler.\n\n### Yayından önce kalite kapıları\n\nDeğişiklikleri prod'a göndermeden önce güvenlik incelemesi zorunlu kılın, yedekleme/geri yükleme tatbikatı yapın ve olayları yeniden oynatarak doğru iş akışı durumunu yeniden oluşturabildiğinizi doğrulayın.\n\nBunlar, denetimleri “sıkıcı” hale getiren uygulamalardır—iyi anlamda.\n\n## Dağıtım, Yayılım ve Değişim Yönetimi\n\nHarika bir onay uygulaması bile herkese bir gecede sunulursa başarısız olabilir. Yayılımı bir ürün lansmanı gibi ele alın: kademeli, ölçümlü ve destekli.\n\n### Aşamalandırarak yayılın (ve kapsamı dar tutun)\n\nGerçek dünya karmaşıklığını temsil eden bir pilot takımla başlayın (bir yönetici, finans, hukuk ve bir üst düzey onaylayıcı). İlk sürümü bir veya iki şablon ve küçük sayıda yönlendirme kuralıyla sınırlayın.\n\nPilot stabil olduktan sonra birkaç departmana genişletin, ardından şirket geneline geçin.\n\nHer aşama için başarı kriterleri tanımlayın: tamamlanan istek yüzdesi, medyan karar süresi, yükseltme sayısı ve en sık reddetme nedenleri.\n\nBir “ne değişiyor” notu yayınlayın ve güncellemeler için tek bir yer belirleyin (ör. /blog/approvals-rollout).\n\n### Veri geçişini planlayın (eski süreci değiştiriyorsanız)\n\nOnaylar şu anda e-posta dizilerinde veya tabloda tutuluyorsa, geçirilecek veri her şeyi taşımak değil, kafa karışıklığını önlemek olmalıdır:\n\n- Mümkünse aktif/akıştaki istekleri içe aktarın veya eski istekleri dondurup yeni sistemde açık etiketlerle yeniden başlatın\n- Önce şablonları, onaylayıcı gruplarını ve politikaları geçirin—günlük işi şekillendiren bunlardır\n- Denetim ve referans için eski sistemin salt okunur arşivini saklayın (veya dışa aktarın)\n\n### Değişim yönetimini bir teslimat olarak planlayın\n\nKısa eğitimler ve rol bazlı hızlı kılavuzlar hazırlayın: istek sahibi, onaylayıcı, admin.\n\n"Onay görgü kuralları" ekleyin: ne zaman bağlam eklenir, yorumlar nasıl kullanılır ve beklenen yanıt süreleri.\n\nİlk birkaç hafta için hafif destek yolu sunun (ofis saatleri + özel kanal). Admin konsolu varsa "bilinen sorunlar ve geçici çözümler" paneli ekleyin.\n\n### Şablon ve kural değişiklikleri için yönetişim oluşturun\n\nKimlerin şablon oluşturabileceğini, yönlendirme kurallarını kimlerin değiştirebileceğini ve bu değişiklikleri kimlerin onaylayacağını tanımlayın.\n\nŞablonları politika belgesi gibi ele alın—sürümleyin, değişiklik için bir gerekçe isteyin ve çeyrek ortasında sürpriz davranış değişikliklerini önlemek için güncellemeleri planlayın.\n\n### Sürekli iyileştirme döngüsü kurun\n\nHer yayılım aşamasından sonra metrikleri ve geri bildirimi gözden geçirin. Şablonları ayarlamak, hatırlatmaları/yükseltmeleri düzeltmek ve kullanılmayan iş akışlarını emekliye ayırmak için çeyreklik incelemeler yapın.\n\nKüçük, düzenli ayarlamalar sistemi ekiplerin gerçek çalışma şekline yakın tutar.
Request (iş nesnesi)
Template (versionlanmış süreç tanımı)
Step (istek için üretilen aşama)
Approver (kullanıcı/grup + nasıl çözüldüğü)
Decision (eklemeli olay günlüğü)
Attachment ve Comment (kontrol ve performans için ayrı varlıklar)
Decision'ların eklemeli (append-only) tutulması, denetimler ve hata ayıklama için kritiktir.