> For the complete documentation index, see [llms.txt](https://docs.useoly.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.useoly.com/otomasyon/workflows/lifecycle-and-history.md). # İş akışı yaşam döngüsü ve geçmişi Devam eden süreçlerin şablondan bağımsızlığı, durumlar, geçmiş ve sorun giderme. Bir ürün **Onaya Gönder** ile başlatıldığında şablonun o andaki adı ve adımları ürün sürecine kaydedilir. Böylece operasyon devam ederken şablon düzenlense bile ürünün karar yolu ortasında değişmez. ## Şablon değişikliklerinin etkisi | Değişiklik | Devam eden süreç | Yeni gönderim | | ----------------------------------- | ----------------------------- | ------------------------- | | Adım ekleme, kaldırma veya sıralama | Değişmez. | Güncel adımları kullanır. | | Rol veya paralel mod değişikliği | Değişmez. | Güncel atamayı kullanır. | | SLA değişikliği | Mevcut son tarihler değişmez. | Güncel SLA ile başlar. | | Ürün tipini şablondan kaldırma | Tamamlanmaya devam eder. | Bu şablondan başlamaz. | | Şablonu pasifleştirme | Tamamlanmaya devam eder. | Yeni süreç başlatmaz. | Aktif süreç sayısı kartta görünür. Aktif süreç varken şablon silinemez. Süreçleri tamamlamak veya ürün tarafında desteklenen iptal sonucuna ulaştırmak gerekir. ## İncelemedeki ürünü değiştirmek İncelemede bir ürünün alanını değiştirip **Kaydet**'i seçerseniz **Onay süreci sıfırlanacak** teyidi açılır. ![İncelemedeki ürünü kaydetmeden önce gösterilen süreç sıfırlama uyarısı](https://67517283-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FP8oDDPbGr8omZPaaGYZf%2Fuploads%2Fgit-blob-268f437c8f837317dc3066af8bbc22b00e61d7a5%2Fworkflow-edit-reset-warning.png?alt=media) *Kaydet ve süreci sıfırla mevcut onay sürecini iptal eder; İptal ise ürünü ve süreci değiştirmeden forma döner.* **Kaydet ve süreci sıfırla** seçildiğinde değişikliğiniz kaydedilir, açık süreç **İptal edildi** olarak kapanır ve ürün **Değişiklik İstendi** durumuna döner. Önceki onaylar yeni sürece taşınmaz. Düzeltmeyi bitirdikten sonra ürünü yeniden **Onaya Gönder** ile başlatmanız gerekir. Bu uyarı, onaylayanın değerlendirdiği içerikle sonradan kaydedilen içeriğin birbirinden ayrılmasını önler. Yalnız yazım hatası gibi küçük bir değişiklikte bile aynı sonuç oluştuğundan, mümkünse düzeltmeyi onaya göndermeden önce tamamlayın. ## Durumlar ve kullanıcı aksiyonu | Süreç sonucu | Ne anlama gelir? | Ne yapmalısınız? | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | Bekliyor / devam ediyor | Geçerli adım karar bekler. | Atanan rolde **Onay Bekleyenler** listesini açın. | | Tamamlandı | Bütün gerekli adımlar onaylanmıştır. | Ürünü son kez kontrol edip ayrı **Yayınla** aksiyonunu değerlendirin. | | Reddedildi | Bir adım ret yorumu ile süreci kapatmıştır. | Ürünü düzeltip yeniden gönderin. | | İptal edildi | İncelemedeki ürün değiştirilip **Kaydet ve süreci sıfırla** ile kaydedilmiştir veya süreç başka desteklenen ürün işlemiyle kapanmıştır. | Ürünün güncel durumunu ve geçmiş açıklamasını kontrol edip yeniden gönderin. | Bu teknik süreç durumları her ekranda ayrı rozet olarak görünmeyebilir; kullanıcı için ürünün **İncelemede**, **Değişiklik İstendi** veya **Onaylandı** durumu ana işarettir. ## Ürün geçmişini okumak Ürün detayında **Geçmişi Gör** veya **Geçmiş** sekmesini açın. İş akışı kayıtları kullanıcı, zaman, kaynak ve durum değişikliğiyle görünür. ![Gönderim ve iki onay adımını gösteren ürün geçmişi](https://67517283-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FP8oDDPbGr8omZPaaGYZf%2Fuploads%2Fgit-blob-93c1572d0a4c64fec69e42ba14796794b14b1244%2Fworkflow-history.png?alt=media) *Onaya gönderim `draft → in_review`, son karar ise `in_review → approved` değişikliğini gösterir.* Geçmişte şu olayları görebilirsiniz: * **Onaya gönderildi**: sürecin kim tarafından ve ne zaman başlatıldığı. * **Onay adımı geçildi**: ara adım kararı ve karar veren kullanıcı. * **Onaylandı**: son adım sonrası ürün durumunun değişmesi. * **Reddedildi**: ret kararı ve zorunlu yorum. * **İptal edildi**: tamamlanmadan kapanan süreç. Arama ve **Tüm İşlemler / Tüm Kaynaklar** filtreleri yoğun geçmişi daraltır. “Değişiklikleri göster” bağlantısı hangi alan veya durumun değiştiğini açar. ## SLA ve gecikme SLA yalnız görünür bir son tarihtir; süre aşımı kendi başına karar vermez. **Bugün SLA Dolacak** ve **SLA Geçmiş** kartları geciken işi bulmaya yardım eder. Mevcut hesaplama ürünün gönderim zamanını temel aldığı için ikinci ve sonraki adımların sürelerini bu başlangıca göre planlayın. Otomatik rol eskalasyonu ürün davranışı olarak doğrulanmadığından, geciken kayıtları filtreyle izleyip ekip içinde elle yönetin. ## Sorun giderme * **Onaya Gönder görünmüyor:** ürün tipinde aktif şablon olup olmadığını, ürünün Taslak veya Değişiklik İstendi durumunda olduğunu kontrol edin. * **Gönderim reddediliyor:** zorunlu alanları, kategori/ürün tipini ve yayın doğrulamasını tamamlayın; aynı üründe açık süreç bulunmadığından emin olun. * **Onay kartını göremiyorum:** doğru tenant ve rolle giriş yaptığınızı, adımın gerçekten sizin rolünüze geldiğini kontrol edin. Önceki adım tamamlanmadan sonraki adım görünmez. * **SLA hemen kısa göründü:** sonraki adım SLA'sı adımın açıldığı andan değil, ürünün gönderildiği andan hesaplanır. * **Şablon silinemiyor:** karttaki aktif süreç sayısını tamamlayın; silme yalnız Admin içindir. * **Onay sonrası ürün yayımlanmadı:** onay ve yayımlama ayrı işlemlerdir; ürün detayındaki **Yayınla** aksiyonunu kullanın. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.useoly.com/otomasyon/workflows/lifecycle-and-history.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.