Belge iş akışı tasarım aracı: Folderit rehberi

Onayları e-postayla toplarken iki soru sık sık karşınıza çıkar: Gerçekte hangi sürüm incelendi ve karar verildikten sonra belge nereye kaydedilmeli? Belge iş akışı tasarım aracı bu adımları tekrar uygulanabilen bir sürece bağlar. Çalışanların her seferinde bir sonraki işlemi hatırlamasını beklemek yerine başlangıcı, kapsamı, görevleri ve sonuçlara göre izlenecek yolları tanımlarsınız.

Folderit Workflow Designer, belge yönetim sisteminin içinde çalışır. Dosya, sürümleri, erişim izinleri ve süreç kayıtları aynı çalışma ortamında kalır. Böylece kararlarla belgeleri ilişkilendirmek kolaylaşır. Sürecin yararlı olması için yine de sorumluları belirlemek, kuralları doğru yapılandırmak ve istisnaları düşünmek gerekir.

İçerik kontrolü, 10 Kasım 2026: Bu yazı, 29 Ocak 2026 tarihli kaynak yazıdan uyarlanmıştır. Açıklamalar güncel dokümantasyona göre düzenlenmiştir. Korunan ekran görüntüsü eski İngilizce arayüzü gösterir. Örnekler açıklayıcı yapılandırmalardır; gerçek bir çalışma alanında yapılmış test sonuçları değildir.

Belge iş akışı tasarım aracı nedir?

Bu araç, belgenin izleyeceği tekrarlanabilir süreci genellikle görsel bir çalışma alanında kurmanızı sağlar. Süreç inceleme, onay, okunduğuna ilişkin teyit, imzalama veya uygun klasöre taşıma içerebilir. Amaç yalnızca daha hızlı bildirim göndermek değildir. Bir işlemin ne zaman başladığını, hangi belgeleri kapsadığını ve bir sorun olduğunda kimin sorumluluk alacağını açıkça göstermektir.

Ekipler çoğu zaman sadece sözleşme ya da fatura onayıyla başlar. Sonra gecikmenin kararın çevresindeki işlerde de oluştuğunu fark ederler: yanlış sürüm gönderilmiştir, ilgili kişi davet edilmemiştir veya onaylanan dosya taslakların arasında kalmıştır. İş akışı tasarımcısı bu geçişleri de sürecin bir parçası haline getirir.

Dört parçalı bir modelle başlayın

Olay → koşullar → adımlar → sonuçlar. Uygulamayı açmadan önce bu dört parçayı yazmak yararlıdır. Başka bir ekip üyesi açıklamanızı okuyarak belirli bir dosyaya ne olacağını anlayamıyorsa süreç henüz yeterince net değildir.

• Olay, otomasyonun başlangıcıdır: yeni dosya sürümü eklenmesi, öğenin taşınması, meta veri değişikliği, etiket veya paylaşım eklenmesi gibi.
• Koşullar, işlemi öğe türü, ad, konum, meta veriler veya tamamlanan talepler bakımından sınırlar. Aynı olayın sistemin başka bir yerinde olması aynı akışı başlatmak zorunda değildir.
• Adımlar, yapılacak işlemleri ve beklemeleri belirler. Bir belge taşınabilir, bir kişiye onay görevi atanabilir veya belirli bir olay beklenebilir.
• Sonuçlar, sonrasında hangi yolun izleneceğini belirler. Koşulun sağlanması, talebin reddedilmesi ve hiç yanıt gelmemesi farklı durumlardır.

Ekiplerin çözmeye çalıştığı dört sorun

Sürüm karışıklığı. Bir kişi önceki metni incelemiş olabilir veya onaydan sonra dosya değişmiş olabilir. Onay, incelenen sürüme ilişkindir; sonradan yüklenen sürüm zaten onaylanmış sayılmaz. Talep açıkken yeni sürüm eklenirse hangi incelemenin geçerli olacağını ekip açıkça belirlemelidir.

Karardan sonraki yönlendirme boşluğu. Belge onaylanmış olsa bile Taslaklar klasöründe kalabilir ya da yanlış projenin içine kaydedilebilir. Sonuca bağlı taşıma, kararı kullanıcıların belgeyi aradığı konumla ilişkilendirir.

Fark edilmeyen paylaşımlar. Gizli bir klasörde yeni erişim paylaşımı oluştuğunda ilgili kişinin haberdar olması gerekir. Olaydan sonra inceleme başlatmak görünürlük sağlar. Bu işlem tek başına paylaşımı önlemez ve alıcının kurum dışından olduğunu otomatik olarak belirlemez.

Eksik süreç kanıtı. Sürüm geçmişi ve karar kayıtları, kimlerin ne zaman hangi içerik üzerinde işlem yaptığını anlamaya yardımcı olur. Bunları gerçek izinler ve uygulanan kontrollerle birlikte değerlendirin. Denetim kaydının bulunması, tek başına mevzuata uyum garantisi değildir.

Folderit’te bir iş akışı nasıl kurulur?

Admin tools > Workflows bölümünü açın, anlaşılır bir ad verin ve otomasyonun etkin olup olmadığını kontrol edin. En az bir Starting point ekleyin; olayı ve dar kapsamlı koşulları seçin. Adlandırılmış bir başlangıç noktası, öğenin Workflow menüsünden elle çalıştırma olanağı da sunabilir.

Dokümantasyondaki olaylar arasında File version added, Item moved, meta veri değişikliği, Tag added, Share added ve Request responded bulunur. Son olay bir talebe yanıt verildiğini bildirir. Bütün katılımcıların onay sürecini bitirdiğini tek başına kanıtlamaz.

Konum koşulunu özellikle dikkatli belirleyin. Klasörün kendisi ile içindeki öğeler aynı şey değildir. İlgili klasörü, bütün alt klasörleri veya belirli sayıda alt düzeyi kapsayacak şekilde seçim yapın. Öğe türü koşuluyla dosyaları, klasörleri ve bağlantıları ayırabilirsiniz. Böylece başka bir alandaki değişiklik gereksiz görev oluşturmaz.

Belgelenen adımlar Condition, Delay, Move, Run automation, Send reminder, Wait for event ve Request action seçenekleridir. Eski ekran görüntüsünde resmî görev için Resolution adını görebilirsiniz. Güncel dokümantasyon bunun için Request action ifadesini kullanır.

Condition adımındaki Success ve Failure çıkışları, koşulun doğru veya yanlış olması anlamındadır. Bunları onay ve ret olarak okumayın. Request action adımının kendi Success, Failure ve Timeout sonuçları vardır. Her birini amaçlanan sonraki işleme bağlayın.

Görevin tamamlanma kuralını açıkça tanımlayın

Kullanıcıları veya grupları seçin; görevlerin paralel mi yoksa sıralı mı yürütüleceğine karar verin. Ardından herkesin, belirli sayıda kişinin veya belirli bir yüzdenin yanıtının gerekip gerekmediğini ve ret eşiğini belirleyin. İlk yanıtın gelmesi, talebin başarıyla tamamlandığı anlamına gelmeyebilir. Görev açıklaması hangi kararın istendiğini ve hangi sürümün inceleneceğini söylemelidir.

Yöntemler arasında Approval, Acknowledgement, Folderit eSign, DocuSign, eID ve Fill fields vardır. İnceleme için özel bir yöntem yapılandırılmış olabilir; her ortamda aynı hazır yöntemin bulunduğunu varsaymayın. İmzalama yöntemlerinin kullanılabilirliği ve ayarları da değişir. Bir yöntemi seçmek kendi başına hukuki uygunluk taahhüdü oluşturmaz.

Due By katılımcıya beklenen son tarihi bildirir. Ayrı bir ayar olan Timeout, otomasyonun ne kadar bekleyeceğini belirler; 0 değeri zaman aşımı olmadığı anlamına gelir. Son tarihin geçmesi kendiliğinden üst sorumluya aktarma sözü vermez. Yanıt gelmediğinde işlem yapılmasını istiyorsanız zaman aşımı yolunu ve konuyu devralacak kişiyi tanımlayın.

Örnek 1: sözleşme incelemesi ve karara göre taşıma

Karara hazır sözleşmelerin Sözleşmeler/İnceleme klasöründe tutulduğunu varsayalım. İlk aşama kararları toplar, ikinci aşama nihai sonuca göre konumu belirler. Bu iki aşama tek bir görsel iş akışında açıkça gösterilebilir:

1. Başlangıcı File version added olayı, Sözleşmeler/İnceleme konumu ve dosya türüyle sınırlandırın. Alt klasörleri yalnızca aynı süreç geçerliyse kapsama alın.
2. Approval yöntemiyle bir Request action ekleyin. Hukuk, finans ve yönetimden sorumlu belirli kişileri seçin. Örneğin hepsini paralel davet edebilir, herkesin onayını isteyebilir ve bir ret yanıtını başarısızlık eşiği olarak belirleyebilirsiniz. Bu örneğin kuralıdır; her kuruma uygun tek seçenek değildir.
3. Success sonucunu Onaylandı, Failure sonucunu Düzeltme klasörüne taşıma adımına bağlayın. Açıkça yapılandırılan Timeout yolu da Üst İnceleme klasörüne gidebilir.
4. Gecikmenin nedenini inceleyip sonraki işlemi belirleyecek sorumluyu atayın. Dosyanın bir klasöre taşınması, bu kişinin vereceği kararın yerini tutmaz.

Bu yapılandırmada katılımcılar bilinçli olarak seçilir. Sistemin meta veride yazan departmandan doğru kişileri kendiliğinden bulduğunu varsaymıyoruz. Sonraki işlemleri ayrı bir otomasyona ayırmak da mümkündür; ancak tamamlanma ve sonuç koşullarını doğru kontrol etmek gerekir. Sadece Request responded olayı, Onaylandı klasörüne taşıma için yeterli değildir.

Talep açıkken yeni sürüm eklenmesini ayrıca değerlendirin. Her olayda gereksiz yinelenen görevler oluşmamalıdır. Ekip mevcut sürümün incelemesini mi tamamladığını yoksa değişen içerik için yeni bir tur mu başlattığını bilmelidir.

Örnek 2: gizli klasördeki paylaşımı incelemek

Gizli proje klasörü için Share added olayını, konum ve öğe türü koşullarıyla sınırlandırın. Ardından belirlenmiş bir güvenlik sorumlusuna Request action atayın. Uygun bir özel inceleme yöntemi varsa onu, yoksa açık talimatlarla Approval yöntemini kullanın.

İnceleyen kişi gerçek alıcıyı, paylaşım kapsamını ve izinleri kontrol eder. Bu akış paylaşım oluşturulduktan sonra tepki verir. Kurum dışı paylaşımı önleyen bir engel, otomatik alıcı sınıflandırması veya otomatik erişim iptali değildir. Hatalı erişimi yetkili kişi gerçek paylaşım kontrolleri üzerinden düzeltmelidir. Belgeyi taşımak, paylaşım bağlantısının iptal edildiğini kanıtlamaz.

İzin verilen normal bir paylaşımı da deneyin; her görevin olay ya da ihlal olarak yorumlanması gerekmemelidir. Belirlenen klasör dışındaki bir paylaşımın akışı başlatmadığını ayrıca kontrol edin.

Kaçınılması gereken üç hata

Kapsamı gereğinden geniş tutmak. Tek bir konumla, doğru öğe türüyle ve gerçekten işlem gerektiren olayla başlayın. Çok sayıda gereksiz görev, kullanıcıların sürece olan güvenini azaltır.

Her işi tek karmaşık akışa yüklemek. Birbirinden bağımsız işlemleri ayırmak okunabilirliği artırabilir. Buna karşılık bir talep ile sonuç yolları, sözleşme örneğindeki gibi anlaşılır kaldığı sürece tek akışta bulunabilir.

Belgenin sonraki konumunu düşünmemek. Taslak → İnceleme → Onaylandı → Arşiv modeli, uygun izinler ve kabul edilmiş kararlarla anlam kazanır. Klasör adı yasal saklama süresi oluşturmaz. Arşive taşıma da otomatik silme anlamına gelmez.

Yaygınlaştırmadan önce kontrol edilecekler

• Kapsamdaki beklenen yeni sürüm süreci başlatıyor mu; kapsam dışındaki öğe hariç kalıyor mu?
• Onay ve ret, belirlenen tamamlanma kurallarından sonra doğru konuma yönleniyor mu?
• Yanıt gelmemesi, yapılandırılan zaman aşımı yolunda bilinen bir sorumluya ulaşıyor mu?
• Açık talep sırasında eklenen sürüm zaten onaylanmış sayılıyor mu veya istenmeyen yinelenen görevler oluşturuyor mu?
• İnceleyen kişi müsait değilse sorumluluğun nasıl devralınacağı belirlenmiş mi?

Başlarken sorulan üç soru

İş akışları yalnızca onay için mi kullanılır?

Hayır. Yönlendirme, okunduğuna ilişkin teyit ve meta veri, etiket ya da paylaşım değişikliklerine kontrollü tepki de yararlıdır. Adımları çözmek istediğiniz somut soruna göre seçin.

Teknik uzman olmamız gerekir mi?

Öncelik süreç, sorumluluklar ve istisnalar üzerinde anlaşmaktır. Görsel tasarım yapılandırmayı kolaylaştırır; yine de koşulların, izinlerin ve tamamlanma kurallarının ne anlama geldiğini kontrol etmelisiniz.

İlk olarak hangi süreci seçmeliyiz?

Bugün gecikmeye veya hataya yol açan bir işlem seçin: sözleşme onayı, politika okuma teyidi ya da paylaşım incelemesi. Olayı, koşulları, adımları ve sonuçları yazın. Sorumluyu belirleyip bu senaryoları kontrol ettikten sonra kapsamı genişletin.

Ayrıntılı ayarlar için Workflow Designer kılavuzuna bakın. Daha geniş çerçeve belge iş akışları sayfasında yer alır. Güncel paket ve imzalama seçeneklerini fiyatlandırma sayfasından kontrol edin.