Workflow tetikleyicileri: iş akışı ne zaman başlamalı?

Bir iş akışının ne yapacağını tasarlamak kadar, ne zaman başlayacağını tasarlamak da önemlidir. Çok geç başlayan bir akış işi yetiştiremez; gereksiz yere başlayan bir akış gürültü üretir; aynı olay için iki kez başlayan bir akış ise iki kayıt, iki e-posta, iki onay isteği demektir.

Workflow tetikleyicisi, bir iş akışını başlatan olaydır. İki ana türü vardır: anlık tetikleyiciler bir olay gerçekleştiğinde (yeni talep, gelen e-posta, sistemdeki bir değişiklik) akışı hemen başlatır; zamanlanmış tetikleyiciler belirli bir saatte veya aralıkta (her gün 08.00, her ayın ilk iş günü) akışı çalıştırır. Doğru tetikleyiciyi seçmek, işin başlaması gereken anı doğru tanımlamakla başlar.

Bu yazıda üç örnek üzerinden tetikleyici türlerini, seçim ölçütlerini ve yanlış tetiklemelerden kaçınma yöntemlerini anlatıyoruz.

İşin başlaması gereken anı belirlemek

Tetikleyici seçmeden önce şu soruyu sorun: "Bu iş gerçek hayatta tam olarak ne zaman başlıyor?"

Cevap her zaman göründüğü kadar açık değildir. Örneğin bir satın alma süreci ne zaman başlar?

• Çalışan ihtiyacı fark ettiğinde mi?
• Talebi yazdığında mı?
• Yöneticisi talebi uygun bulduğunda mı?
• Stok seviyesi belirli bir eşiğin altına düştüğünde mi?

Her cevap farklı bir tetikleyiciye işaret eder. Doğru cevap, sürecin sahibinin "İşi buradan itibaren takip etmek istiyorum" dediği andır.

Tetikleyici türleri

Örnek 1: Yeni talep (anlık tetikleyici)

Aşağıdaki örnekler temsilidir.

Bir teknik servis firmasında müşteriler arıza bildirimini web sitesindeki formdan, WhatsApp hattından veya çağrı merkezinden iletiyor. Hedef: her bildirimin 15 dakika içinde kayda geçmesi ve doğru teknisyene atanması.

Tetikleyiciler:

• Web formu gönderildiğinde → webhook
• WhatsApp hattına mesaj geldiğinde → kanal olayı
• Çağrı merkezi temsilcisi kayıt açtığında → API çağrısı

Akış:

1. Talep bilgileri yapılandırılır (müşteri, cihaz, arıza tanımı, adres).
2. Müşteri kaydı CRM'de bulunur; garanti durumu kontrol edilir.
3. Arıza türü sınıflandırılır (yapay zeka).
4. Bölgeye ve uzmanlığa göre uygun teknisyen önerilir.
5. Servis koordinatörü atamayı onaylar.
6. Müşteriye randevu bilgisi gönderilir.

Neden anlık? Çünkü müşteri beklemektedir ve her dakika önemlidir. Talebi saatlik bir toplu kontrolle almak, müşteri deneyimini doğrudan bozar.

Örnek 2: Günlük stok kontrolü (zamanlanmış tetikleyici)

Bir yedek parça distribütörü, kritik ürünlerin stok seviyesini takip etmek istiyor. Hedef: stok kritik seviyeye düşen ürünler için satın alma ekibinin her sabah bir liste ve tedarik önerisi alması.

Tetikleyici: Her iş günü saat 07.30.

Akış:

1. ERP'den kritik ürün listesinin güncel stok seviyeleri okunur.
2. Minimum stok seviyesinin altındaki ürünler belirlenir (kural).
3. Son 30 günlük satış hızına göre kaç günlük stok kaldığı hesaplanır (sistem).
4. Açık siparişler kontrol edilir; yolda olan ürünler listeden çıkarılır.
5. Kalan ürünler için tedarikçi ve son alım fiyatıyla bir öneri listesi hazırlanır.
6. Liste, kısa bir özetle satın alma ekibine gönderilir.

Neden zamanlanmış? Stok seviyesi gün içinde sürekli değişir; her satışta bir akış başlatmak gereksiz gürültü üretir. Satın alma ekibi zaten günlük bir ritimle çalışır; sabah listesi bu ritme uyar.

Hibrit yaklaşım

Bazı durumlarda ikisi birlikte kullanılır. Yukarıdaki örnekte günlük kontrol devam ederken, stoğu sıfıra düşen bir ürün için anlık bir uyarı da tetiklenebilir. Böylece rutin iş zamanlanmış akışta, acil durum anlık akışta yönetilir.

Örnek 3: Aylık rapor (zamanlanmış, takvime bağlı)

Bir franchise zincirinin genel müdürlüğü, her ayın ilk iş günü şube bazında satış, müşteri şikâyeti ve personel devir özetini içeren bir rapor istiyor.

Tetikleyici: Her ayın ilk iş günü, saat 09.00.

Akış:

1. Önceki ayın satış verileri muhasebe sisteminden alınır.
2. Şikâyet kayıtları destek sisteminden alınır ve konu başlıklarına göre sınıflandırılır (yapay zeka).
3. Personel giriş-çıkış verileri İK sisteminden alınır.
4. Önceki ayla karşılaştırma yapılır; dikkat gerektiren şubeler işaretlenir.
5. Yapay zeka her dikkat çeken şube için kısa bir açıklama taslağı hazırlar.
6. Rapor, operasyon müdürünün onayına sunulur.
7. Onaylanan rapor yönetim ekibine gönderilir.

Dikkat edilecek nokta: "Ayın ilk iş günü" tanımı, resmi tatilleri ve hafta sonlarını hesaba katmalıdır. 1 Ocak veya bayram tatiline denk gelen ay başlarında akışın doğru günde çalışması için takvim kuralı gerekir.

Anlık ve zamanlanmış akışlar: karar tablosu

Yanlış ve yinelenen tetiklemelerden kaçınmak

Tetikleyici tasarımındaki hataların etkisi genellikle akış canlıya alındıktan sonra fark edilir: aynı müşteriye iki e-posta gider, aynı talep için iki kayıt açılır veya akış hiç çalışmaz.

Yaygın hatalar ve çözümleri

Tekillik kontrolü neden önemli?

Webhook gönderen sistemlerin çoğu, karşı taraftan onay alamadığında aynı olayı yeniden gönderir. Bu, ağ sorunlarında olayın kaybolmaması için iyi bir özelliktir; ancak alıcı taraf aynı olayı iki kez işlerse sorun çıkar. Çözüm, her olayın benzersiz kimliğini kaydetmek ve aynı kimlikle gelen ikinci olayı yok saymaktır.

Tetikleyici izleme

Canlıdaki bir akış için şu soruların cevabını her zaman bilebilmelisiniz:

• Akış son olarak ne zaman tetiklendi?
• Son 24 saatte kaç kez tetiklendi? Bu sayı olağan mı?
• Başarısız olan tetiklemeler var mı? Neden?
• Zamanlanmış akış beklenen saatte çalıştı mı?

Olağan dışı bir düşüş (akış hiç çalışmadı) veya artış (akış yüzlerce kez çalıştı) genellikle bir tetikleyici sorununa işaret eder.

Tetikleyici tasarım kontrol listesi

• İşin gerçekte başladığı an tanımlandı
• Tetikleyici türü (anlık, zamanlanmış, hibrit) seçildi
• Birden fazla kaynak varsa hepsi aynı akışa bağlandı
• Tetikleme koşulları yazıldı (hangi durumda başlamamalı?)
• Olay kimliğiyle tekillik kontrolü eklendi
• Akışın kendi değişikliğiyle döngüye girmesi engellendi
• Zamanlamalar Türkiye saatine göre ve iş günü takvimiyle tanımlandı
• Başarısız tetiklemeler için yeniden deneme ve uyarı kuruldu
• Tetikleme sayıları izleniyor

ajan.io'da tetikleyiciler

ajan.io'da iş akışları API çağrısı, webhook, zamanlama, sohbet içindeki bir talep, bağlı bir araçtaki olay, gelen e-posta veya başka bir iş akışıyla başlatılabilir. Kullanıcının akışı başlatmak için ajan.io paneline girmesi gerekmez. Zamanlanmış işler arka planda çalışır; başarısız adımlar yeniden denenir ve akışın durumu izlenebilir.

Tetikleyicilerin iş akışı tuvalinde nasıl göründüğünü İş akışları sayfasında inceleyebilirsiniz. İş akışı tasarımının temelleri için AI workflow nedir? yazımıza bakın.

Sık sorulan sorular

Webhook ile API çağrısı arasındaki fark nedir?

İkisi de sistemler arasında veri iletir. API çağrısında bir sistem, diğerinden bilgi veya işlem ister. Webhook'ta ise bir sistem, kendisinde bir olay gerçekleştiğinde bunu önceden tanımlı bir adrese kendiliğinden bildirir. Tetikleyici açısından webhook "olay oldu, haber veriyorum", API çağrısı ise "şu işi başlat" anlamına gelir.

Kaynak sistem webhook desteklemiyorsa ne yapmalıyım?

Bu durumda zamanlanmış bir tetikleyiciyle kaynak sistem belirli aralıklarla sorgulanabilir: örneğin her 15 dakikada bir "son kontrolden bu yana yeni kayıt var mı?" diye bakılır. Bu yöntemde tepki süresi sorgulama aralığına bağlıdır ve tekillik kontrolü özellikle önemlidir.

Aynı süreç için birden fazla tetikleyici kullanmak karmaşıklık yaratmaz mı?

Her tetikleyici talebi aynı yapıya dönüştürüp aynı akışa soktuğunda karmaşıklık artmaz, aksine süreç tek yerden yönetilir. Karmaşıklık, her kanal için ayrı akışlar kurulduğunda ortaya çıkar; o durumda kurallar zamanla birbirinden ayrışır.

Zamanlanmış akış çalışırken sistem kapalıysa ne olur?

İyi tasarlanmış bir akışta başarısız adım belirli aralıklarla yeniden denenir. Yeniden denemeler de başarısız olursa, akış sorumlu kişiye bir uyarı göndermeli ve işin manuel olarak tamamlanması gerektiğini bildirmelidir. Sessizce başarısız olan bir zamanlanmış akış, çoğu zaman ancak rapor gelmediğinde fark edilir.