11 Haz 2025·8 dk
İçerik Onay Süreçleri İçin Web Uygulaması Nasıl Oluşturulur
İçerikleri inceleme ve onay süreçlerinden geçiren bir web uygulaması için iş akışları, roller, durumlar, kullanıcı arayüzü ve entegrasyonları tasarlama adım adım rehberi.
İçerikleri inceleme ve onay süreçlerinden geçiren bir web uygulaması için iş akışları, roller, durumlar, kullanıcı arayüzü ve entegrasyonları tasarlama adım adım rehberi.
Ekranları tasarlamadan veya bir veritabanı seçmeden önce ne inşa ettiğinizi netleştirin: içerği “birisi başladı”dan “onaylandı ve yayınlandı”ya taşıyan, ve herkesin bir sonraki adımın ne olduğunu bildiği bir sistem.
Bir içerik onay boru hattı, içeriğin geçmesi gereken adımların—taslak oluşturma, inceleme, onay ve yayınlama—ve içeriği kimlerin ilerletebileceğine dair kuralların toplamıdır. Bunu trafik ışıklı paylaşılan bir kontrol listesi gibi düşünün: içeriğin mevcut bir durumu, bir sonraki adımı ve sorumlu kişi vardır.
Amaç bürokrasi eklemek değil. Amaç dağınık e-postaları, sohbetleri ve "latest_final_v7" gibi dosyaları tek bir yerde toplayıp güncel sürüm ve kararın açıkça görünmesini sağlamaktır.
Çoğu ekip birkaç rolde toplanır (uygulamanız bunları roller, gruplar veya izinler olarak uygulayabilir):
Kuruluş yapısı karmaşık olsa bile, uygulamanız günlük deneyimi basit tutmalı: "Benim beklememde olan ne?" ve "Bir sonraki adım ne?"
Bir boru hattı uygulaması genellikle tek bir içerik türüyle başlar, sonra genişler. Yaygın türler şunlardır:
Bu önemlidir çünkü iş akışı aynı olsa bile veri ve kullanıcı arayüzü farklılık gösterebilir. Örneğin, ürün sayfaları alan düzeyinde inceleme gerektirebilirken, makaleler zengin metin ve editoryal yorumlar gerektirebilir.
Takımın hissedebileceği çıktı bazlı hedefler tanımlayın:
Eğer ölçülebiliyorsa daha iyi—taslaktan onaya geçen süre, revizyon döngülerinin sayısı ve gecikmiş incelemeler gibi. Bu hedefler iş akışı tasarımınızı ve raporlamanızı yönlendirir.
Herkes bir bakışta iki soruyu yanıtlayabildiğinde bir içerik onay uygulaması kullanımı kolay olur: "Bu öğe hangi durumda?" ve "Bir sonraki ne olabilir?". Küçük, açık ve birbirini dışlayan durumlar tanımlayarak başlayın, sonra içeriği bu durumlar arasında hareket ettiren kuralları belirleyin.
Yaygın bir temel model şu şekildedir:
Taslak → İnceleme → Değişiklik Gerekiyor → Onaylandı → Zamanlandı/Yayınlandı
Durum isimlerini kullanıcı dostu tutun ("Revizyonlar" yerine "Değişiklik gerekiyor" gibi) ve her durumun bir sonraki kimin harekete geçmesi gerektiğini ima ettiğinden emin olun.
"Onaylandı"nın tek bir karar mı yoksa birden fazla kontrolden mi oluştuğuna karar verin.
Çok adımlı onay gerekiyorsa (ör. önce Hukuk sonra Marka), bunu açıkça modelleyin:
Seçenek B durum listesini daha kısa tutar, ama ilerlemeyi açıkça göstermeniz gerekir (ör. “3 inceleyiciden 2'si onayladı” gibi).
İzin verilen hareketleri yazın ve bunları tutarlı uygulayın:
Ayrıca "geri" geçişlerin onayları koruyup korumadığına veya sıfırlayıp sıfırlamadığına karar verin (çoğu ekip içerik değiştiğinde onayları sıfırlar).
Paralel incelemeler daha hızlıdır: birden fazla inceleyici aynı anda onay verebilir ve onay için tümünün mü yoksa herhangi birinin mi gerektiğine karar verirsiniz.
Sıralı incelemeler daha katıdır: içerik adım adım ilerlemelidir (uyumluluk için yararlıdır). Her ikisini de destekliyorsanız, bunu iş akışı başına bir ayar yapın ki ekipler süreçlerine uygun olanı seçebilsin.
İçerik onay iş akışı, insanlar ne yapabileceklerinden emin olmadığında veya bir şey takıldığında kimin sorumlu olduğuna dair belirsizlik ortaya çıktığında en hızlı şekilde başarısız olur. Özellikleri inşa etmeden önce açık roller, her aşamada her rolün ne yapabileceği ve içerik ilerledikçe sahipliğin nasıl değişeceğini tanımlayın.
Uygulamanızın desteklediği eylemleri (oluştur, düzenle, yorum yap, değişiklik iste, onayla, yayınla, arşivle) listeleyin ve bunları rollere eşleyin. Basit bir temel şöyle olabilir:
"Yayınlama"yı "onaylama"dan ayrı tutun eğer ekstra bir güvenlik kontrolü isterseniz.
Çoğu ekip bağlama göre değişen kurallara ihtiyaç duyar:
Amaç, bir cümlede açıklanabilecek bir izin modeli sunmaktır: "İzinler proje bazında atanır ve iş akışı aşamasına göre uygulanır." Kullanıcıların bunu anlamak için eğitim alması gerekiyorsa, model çok karmaşıktır.
Her öğe için saklayın:
Onaylar tatildeyken sürecin tıkanmaması için devretme ekleyin: yedek onaycılar, geçici rol devri ve "X gün sonra otomatik yeniden atama" gibi kurallar.
Adminlerin işi ilerletirken güveni zedelemeden işleri devam ettirebilmeleri gerekir: rollerin yönetimi, izin kontrollerinin görüntülenmesi, çatışmaların çözülmesi (ör. iki onaycı anlaşmazsa) ve öğelerin yeniden atanması için gerekçe talep etme gibi. Bunu görünür kılacak bir denetim kaydıyla eşleştirin (sonraki bölümde ele alınacak).
Veri modeli, bir onay boru hattını esnek tutacak veya değişmesi zor bir hal aldıracak yerdir. Sürümleme, tartışmalar ve izlenebilirliği destekleyen bir yapı hedefleyin; her gelecekteki özelliği tek bir "içerik" tablosuna zorlamayın.
Pratik bir temel genellikle şunları içerir:
id, type, owner_id, mevcut status ve zaman damgaları gibi kalıcı meta verileri saklar.title, body, tags, yapılandırılmış alanlar). Bir ContentItem'in birçok Version'ı olur.Raporlamayı daha sonra kolaylaştırmak için ilişkileri açıkça modelleyin:
current_version_id gibi bir işaretçi)Dosyaları destekliyorsanız, ekleri Versiyon'a (veya Yoruma) bağlayan bir Attachment ekleyin ki varlıklar incelenen kesin revizyona bağlı kalsın.
İş akışınız sabitse enum basit ve hızlıdır (ör. Draft → In Review → Approved → Published).
Müşterilerin özel durumlara ihtiyacı varsa (WorkflowState, WorkflowTransition gibi) yapılandırılabilir tablolar kullanın ve mevcut durumu yabancı anahtar olarak saklayın. Bu, her değişiklik için kod dağıtımı gerektirmez ancak başlangıçta daha maliyetlidir.
Basit içerikler bile öngörülebilir yapıdan fayda sağlar: title, body, summary, tags artı içerik türüne özgü alanlar için opsiyonel JSON. İnceleyicilerin bağlamı dışarıda aramaması için kaynaklar, biletler veya ilgili sayfalar gibi Referans bağlantıları ekleyin.
UI, onay boru hattınızı kullanıcılar için gerçek kılan yerdir. İki ana yüzeye odaklanın—Taslak Oluşturma ve İnceleme—ve iş akışını her zaman görünür tutun ki kimse ne yapılacağı konusunda tahminde bulunmasın.
Editör ekranında iş akışı bağlamı için tutarlı bir başlık alanı ayırın:
Eylemleri bağlama göre gösterin: "İncelemeye gönder" yalnızca taslak yeterince geçerli olduğunda görünmeli; "Taslağa geri al" ise sadece izin verilen roller için olmalı. Kazara gönderimleri önleyecek hafif kontroller (başlık eksik, özet boş) ekleyin ama editörü form doldurma işkencesine dönüştürmeyin.
İnceleyiciler zamanlarını okumaya ve karar vermeye harcamalı—düğmeleri aramaya değil. Bölünmüş bir düzen kullanın: bir tarafta içerik, diğer tarafta inceleme araçları. Kolaylaştırın:
Bir revizyon gönderildiğinde, sürümler arasındaki diff görünümü ve kısa bir değişiklik özeti gösterin ("Son incelemeden bu yana ne değişti?"). Bu, yinelenen geri bildirimleri önler ve yeniden onayı hızlandırır.
Birden çok öğeyi inceleyen ekipler için liste görünümünde toplu eylemler ekleyin: birden fazla onayı vermek, birden fazla öğede değişiklik istemek veya farklı bir inceleyiciye atamak—ancak değişiklik talep ederken kısa bir not gerektirin ki kararlar izlenebilir kalsın.
Bildirimler, içerik onay iş akışını "canlı" hissettiren şeydir. Doğru yapıldığında incelemeleri harekete geçirir; kötü yapıldığında kullanıcıların her şeyi görmezden gelmesine neden olur.
Gerçek zamanlı farkındalık için uygulama içi bildirimler (zil simgesi, gelen kutusu, okunmamış sayıları) ile başlayın. Mesajları kısa ve aksiyon odaklı tutun: ne değişti, kim yaptı ve sonraki beklenen adım ne. Kullanıcılar oturum açmadıklarında önemli olaylar için e‑posta ekleyin: incelemeye atanma, birinden bahsedilme veya yaklaşan son tarih gibi. Ekipler sohbeti yoğun kullanıyorsa, entegrasyon aracılığıyla isteğe bağlı Slack/Teams gönderimleri sunun (ör. bir öğe İnceleme'ye girdiğinde kanala gönder). Bu seçenekleri çalışma alanı veya proje bazında isteğe bağlı yapın.
Hatırlatmalar duyguya değil, net zaman kurallarına bağlı olmalıdır.
Örneğin:
Hatırlatmaları akıllı yapın: inceleyici dışarıdaysa (takip ediyorsanız) bastırın ve bir yorum veya karar gönderildiğinde tekrar hatırlatmayı durdurun.
Kullanıcıların şu seviyelerde abone olmalarına izin verin:
Abonelikler "bilgi için" (FYI) bildirimlerini azaltır ve paydaşların güncellemeleri self‑serve olarak almasını sağlar.
Her kullanıcıya bir bildirim ayarları sayfası verin ( /settings/notifications içinden bağlayın) ve şunları sunun:
Tasarım ilkesi: daha az, daha net bildirim gönderin—her biri "ne oldu?" ve "sırada ne yapmalıyım?" sorularını yanıtlamalıdır.
İçerik incelemeden geçerken, geçmiş genellikle mevcut durumdan daha önemlidir. Bir denetim izi, birisi "Bunu kim onayladı?" veya "Neden o sürümü yayınladık?" diye sorduğunda sizi korur. Ayrıca kararları görünür kılarak iç sürtüşmeyi azaltır.
Değiştirilmez bir olay günlüğü ile başlayın: üzerine ekleme yaptığınız, üzerine yazmadığınız kronolojik bir kayıt. Her giriş dört soruyu yanıtlamalı—kim, ne, ne zaman ve neden.
Günlüğü teknik olmayan kullanıcılar için okunabilir tutun: insan dostu zaman damgaları, isimler (ID'ler değil) ve tam durum geçişlerini gösterin (Taslak → İnceleme → Onaylandı). "Değişiklik isteği" adımınız varsa, istenen değişiklikleri yapılandırılmış alanlar (kategori, şiddet) olarak kaydedin ve serbest metin yorumlara ekleyin.
Denetim izleri kararları açıklar; sürüm geçmişi içerik değişikliklerini açıklar. İçerik gövdesi, başlık, meta veri veya kritik alan değiştiğinde yeni bir sürüm kaydedin.
UI'da değişiklikleri vurgulayın: sürümler arasındaki farkları gösterin (basitçe "önce/sonra" görünümü bile işe başlar).
Denetimler uygulamanın dışında da olur.
Saklama kurallarını erken kararlaştırın (ör. günlükleri 2–7 yıl sakla) ve dışa aktarımları tarih aralığı, içerik öğesi ve iş akışı aşamasına göre filtrelenebilir yapın, böylece binlerce satırı tek seferde dökmeyin.
Onay boru hattınız birkaç öğeyi aştığında, insanlar gezmek yerine bulmaya başlar. İyi arama ve görünümler uygulamanızı bir listeden güvenilir bir çalışma aracına dönüştürür.
Başlık, gövde ve yorumlar gibi inceleyicilerin referans verdiği yerlerde tam metin aramayı destekleyin. Sonuçları öne çıkan eşleşmeler ve temel bağlam (durum, proje, mevcut atanan) ile tahmin edilebilir hissettirin. Uzun içerik saklıyorsanız, yalnızca gerekenleri indeksleyin (ör. en son sürüm ve yorumlar) ki sonuçlar hızlı ve alakalı olsun.
Küçük bir dokunuş: teknik olmayan kullanıcıların anlayacağı arama operatörleri ("marka sesi" gibi ifadeyi tırnak içine alma veya arama çubuğunda etiketle filtreleme).
Filtreler "Sırada benim için ne var?" ve "Nerede işler tıkalı?" sorularını cevaplamalıdır. Yaygın filtreler:
Filtreleri serbestçe birleştirin ve bunları çıkarılabilir chipler olarak gösterin ki kullanıcılar bir listenin neden o öğeleri içerdiğini görebilsin.
Kullanıcıların filtre setlerini "Benim incelemem gerekenler" veya "Hukuk için gecikmişler" gibi adlandırılmış görünümler olarak kaydetmesine izin verin. Ekipler paylaşılan görünümleri kenar çubuğuna sabitlemek isteyebilir; böylece herkes aynı kuyruktan çalışır. İzinlere dikkat edin: kaydedilmiş görünüm yalnızca görüntüleyenin erişebileceği öğeleri göstermelidir.
Panellerin gösterişli olması gerekmez; işe yarayan birkaç net metrikle başlayın: durumlara göre öğe sayısı, aşama başına ortalama çevrim süresi ve işin yığıldığı yerler. Bir aşama sürekli yavaşsa, bu personel veya politika sorununa işaret eder—raporlamanız bunu açık hale getirmeli.
API'niz UI, entegrasyonlar ve iş akışı kuralları arasındaki sözleşmedir. Tutarlıysa ürün öngörülebilir hisseder; tutarsızsa her ekran ve entegrasyon tek seferlik olur.
REST genellikle onay boru hattı web uygulaması için en basit uyumdur çünkü iş akışı eylemleri kaynaklara (öğeler, incelemeler, kararlar) net şekilde eşlenir ve önbellekleme, günlükler ve araçlar basit kalır.
GraphQL, birçok ekranın aynı içerik öğesinin farklı "şekillerine" ihtiyaç duyduğu durumlarda faydalı olabilir (taslak + inceleyiciler + geçmiş tek çağrıda). GraphQL kullanırsanız bile iş akışı eylemlerini açıkça modelleyin (mutations) ve isimlendirmeyi durum makinenizle tutarlı tutun.
İki fikir etrafında tasarlayın: (1) içerik öğesi çekirdek kaynaktır ve (2) iş akışı eylemleri açık operasyonlardır.
Pratik bir REST seti şöyle olabilir:
GET /content?status=in_review&cursor=... (listeleme)GET /content/{id} (detay)POST /content/{id}/workflow/request-reviewPOST /content/{id}/workflow/decision (onay / değişiklik iste / reddet)POST /content/{id}/workflow/transition (admin‑özgü geçişler, izin veriliyorsa)İstek gövdelerini sade ve tutarlı tutun:
{ "action": "approve", "comment": "Looks good.", "assignedTo": "user_123" }
/approveContentNow veya PUT /content/{id}/status gibi doğrulamayı atlayan uç noktalardan kaçının—bunlar genellikle iş akışını güvenilir kılan kuralları atlar.
İş akışı işlemleri sıkça yeniden denenir (mobil ağlar, kuyruk tekrarları, webhook yeniden teslimleri). Durum değiştiren istekleri Idempotency-Key başlığı kabul ederek idempotent yapın ve tekrar edilen çağrılar için aynı sonucu döndürün.
Ayrıca iyimser eşzamanlılık düşünün:
GET /content/{id} içinde bir version (veya etag) dahil edinIf-Match (veya version) isteyin ki "son yazma kazanır" kazalarını önleyinOnay araçları liste ekranlarında yaşar: "İncelemem gerekenler", "Hukuk bekleyenler", "Benim atamalarım". Baştan sayfalandırma uygulayın—cursor tabanlı sayfalandırma verinin değişmesiyle daha stabil kalır.
GET /content?status=needs_changes&limit=50&cursor=...Arama‑yoğun uç noktalar için makul hız sınırları ekleyin ve açık başlıklar döndürün (ör. kalan istekler, sıfırlama zamanı). Bu, sisteminizi korur ve entegrasyon hatalarını teşhis etmeyi kolaylaştırır.
Entegrasyonlar, onay boru hattını "başka bir araç" olmaktan çıkarıp ekiplerin zaten içerik oluşturup incelediği şekilde çalışmasına sokar. Amaç basit: kopyala‑yapıştırı azaltmak, kaynak dosyaları bağlı tutmak ve bir sonraki adımı otomatikleştirmek.
Pratik bir içerik iş akışı uygulaması genellikle birkaç sisteme bağlanır:
Diğer araçların tepki verebilmesi için küçük, güvenilir bir olay seti sunun:
content.approvedcontent.rejectedcontent.publishedreview.requestedHer webhook içerik ID'si, mevcut durum, zaman damgaları ve uygulamanıza dönüş URL'lerini içermeli. Yükleri ve imzalama stratejisini /docs/api gibi basit bir referansta belgeleyin.
Takımlar nadiren sıfırdan başlar. Şunları destekleyin:
Burada tek bir "güçlü özellik" inşa etmeniz gerekse, onu idempotent yapın: aynı dosyayı iki kez içe aktarmak çoğaltma oluşturmasın.
Bir içerik onay iş akışı uygulaması çoğunlukla "iş kuralları + izinler + denetlenebilirlik"ten ibarettir. Bu iyi haber: doğru yapmak için egzotik teknolojiye ihtiyacınız yok. Ekibinizin güvenle dağıtabileceği ve sürdürebileceği araçları seçin, sonra mimariyi tahmin edilebilir iş akışı operasyonları etrafında tasarlayın (taslak oluştur → inceleme iste → onay/reddet → yayınla).
Eğer ürünü tam inşa etmeden önce doğrulamak istiyorsanız, iş akışı UI'sını, rolleri ve bildirimleri hızla vibe‑kodlama bir platformda prototipleyebilirsiniz, örneğin Koder.ai. Çünkü sohbetten tam uygulamalar (React UI'lar ve Go + PostgreSQL backend dahil) oluşturduğu için, burada tanımladığınız durum makinesini ve izin kurallarını çalışan bir iç araca dönüştürmek için pratik bir yoldur; hazır olduğunuzda kaynak kodu dışa aktarma seçeneği de mevcuttur.
UI için React veya Vue iyi seçeneklerdir—ekibinizin zaten bildiğini seçin. Formlar, tablolar, modaller ve durum rozetleri için bir bileşen kütüphanesi (ör. Material UI, Ant Design, Vuetify) ile eşleştirin ki formlar, tablolar ve rozetler üzerinde hızlı ilerleyin.
Temel UI ihtiyaçları tekrarlayıcıdır: durum chipleri, inceleyici kuyrukları, diff görünümleri ve yorum dizileri. Bir bileşen kütüphanesi bu ekranları tutarlı tutmanızı sağlar.
Her ana akım backend onay boru hattını idare edebilir:
Önemli olan, iş akışı kurallarını net şekilde uygulayabilmeniz, izinleri zorunlu kılmanız ve denetim izini kaydetmenizdir. İş mantığını test etmeyi kolaylaştıran ve controller'ları ince tutan frameworkleri tercih edin.
İlişkisel iş akışı verileri için Postgres kullanın: içerik öğeleri, sürümler, iş akışı durumları, atamalar, yorumlar, onaylar ve izinler. Onay sistemleri net ilişkiler ve işlemlerle iyi çalışır.
Yüklemeler (görseller, PDF'ler, ekler) için nesne depolama (S3 uyumlu) kullanın ve yalnızca meta veriyi + URL'leri Postgres'te saklayın.
Bildirimler, hatırlatmalar ve dış webhook'lar istek/yanıt döngüsünde değil, arka plan çalışanlarında çalışmalıdır. Bu sayede sayfa yüklemeleri yavaşlamaz ve yeniden denemeler kolaylaşır.
Tipik işler:
Modüler bir monolit ile başlayın: bir backend servisi, bir veritabanı, bir iş kuyruğu. Sınırları (iş akışı motoru, izinler, bildirimler) net tutun ki isterseniz daha sonra servisleri ayırabilesiniz. Bu sınırların bir API perspektifinden nasıl göründüğünün bir ön izlemesini isterseniz, /blog/api-design-for-workflow-operations gibi kaynaklara bakabilirsiniz.
Bir içerik onay iş akışı, acil düzeltmeler, birden fazla inceleyici ve çok sayıda bildirim altında öngörülebilir davrandığında ancak "tamamlanmış" sayılır. Test ve operasyonu ürünün bir parçası olarak ele alın.
Sistem bütünlüğünü tanımlayan kurallar etrafında unit testleri ile başlayın:
Sonra uçtan uca onay akışlarını doğrulayan entegre testleri ekleyin. Bu testler eylemlerin durumu doğru güncellediğini, doğru görevleri oluşturduğunu ve bildirimleri (e‑posta/uygulama içi) doğru zamanda tetiklediğini doğrulamalıdır—çoğaltma olmadan.
Prodüksiyondan önce, gerçekçi inceleme senaryolarını yansıtan başlangıç verisi ve staging ortamı koruyun: birden fazla rol, örnek içerik türleri ve değişen son tarihler. Bu paydaşların akışı doğrulamasını sağlar ve ekibin hataları hızlıca yinelemesini kolaylaştırır.
Pratik bir dağıtım kontrol listesi şunları içerir:
Lansmandan sonra sürekli bakım esas olarak sorunları erken fark etmekle ilgilidir:
İzlemeyi hafif operasyonel rutinlerle eşleştirin: hataların haftalık gözden geçirilmesi, uyarı ayarlarının düzenlenmesi ve periyodik izin denetimleri. Eğer ileride iş akışı değişiklikleri ekleyecekseniz, bunları feature flag arkasında yayınlayın ki ekipler kesintisiz benimseyebilsin.
Bir içerik onay akışı, içeriğin net durumlar arasında ilerlemesini sağlayan tanımlı bir iş akışıdır (ör. Taslak → İnceleme → Onaylandı → Yayınlandı) ve içeriği ilerletebilecek kişilere dair kuralları içerir.
E-posta, sohbet ve dosya adlarıyla dağınık geri bildirim yerine durum, sonraki adım ve sorumluluk için tek bir gerçek kaynak sağlar.
Çoğu ekip en az beş role ihtiyaç duyar:
Bunları roller, gruplar veya izinler olarak uygulayabilirsiniz; fakat kullanıcı arayüzü her zaman "Benim beklememde olan ne?" sorusunu yanıtlamalıdır.
Bir sonraki aktörü açıkça çağrıştıran, küçük ve birbirini dışlayan durumlarla başlayın, örneğin:
İsimleri kullanıcı dostu tutun (ör. “Değişiklik gerekiyor” "Revizyonlar" yerine) ve izin verilen geçişleri zorlukla uygulayın ki kullanıcılar gerekli kontrolleri atlamasın.
Tek adımlı onay küçük ekipler veya düşük riskli durumlar için uygundur.
Çok adımlı onay belirli grupların (hukuk, marka, uyumluluk) imzasını gerektirdiğinde kullanılır. İki yaygın model:
İkincisini seçerseniz ilerlemeyi açıkça gösterin (ör. “2/3 onay tamamlandı”).
Önceden geçiş kurallarını tanımlayın ve tutarlı uygulayın:
Çoğu ekip, gözden geçirilen içerik değiştiğinde önceki onayları sıfırlar; böylece kararlar belirli bir sürüme bağlı kalır.
Sürümleme ve izlenebilirliği kolaylaştıran temel varlıklarla başlayın:
İş akışınız sabitse enum basit ve hızlıdır.
Eğer müşteri/ekip başına özel durumlar bekliyorsanız (ör. "SEO Kontrolü", "Hukuk İncelemesi"), WorkflowState ve WorkflowTransition gibi yapılandırılabilir tablolar kullanın ve mevcut durumu yabancı anahtar olarak saklayın. Bu, her değişiklik için kod dağıtımı gerektirmez.
Genellikle iki temel ekran ürünü taşır:
Ayrıca bir diff görünümü ve kısa "ne değişti" özeti, tekrar eden geri bildirimleri azaltır ve yeniden onay sürecini hızlandırır.
Varsayılan olarak uygulama içi bildirimleri kullanın; e-posta/sohbet ise daha yüksek öncelikli olaylar için olsun.
İyi hatırlatmalar SLA tabanlı olmalıdır (ör. incelemede 48 saat sonra hatırlatma; 72 saat sonra yedek kişiye bildirim). Ögeler için:
İnceleyici işlem yaptıktan sonra hatırlatmaları durdurun ve gereksiz FYI gürültüsünden kaçının.
API'nizi kaynaklar ve açık iş akışı eylemleri etrafında tasarlayın:
GET /content/{id}POST /content/{id}/workflow/request-reviewPOST /content/{id}/workflow/decision (onay/değişiklik talebi/reddet)Güvenilirlik için:
Bu yapı raporlama ve denetimler için ileride büyük kolaylık sağlar.
Idempotency-Key desteğietag/If-Match veya sürüm alanları)Doğrulama atlayan ham PUT /content/{id}/status gibi uç noktalardan kaçının.