.jpeg)
Workflow Rule ve Process Builder'ın emekliye ayrılmasıyla birlikte Flow, Salesforce'ta deklaratif otomasyonun tek merkezi haline geldi. Ancak org'lardaki flow sayısı arttıkça yeni sorunlar da ortaya çıktı: Hangi flow ne iş yapıyor, bir değişikliği kim ne zaman yaptı, bir flow'u her seferinde elle debug etmeden nasıl test ederiz?
12 Ekim 2026'da yayına girecek olan Winter '27 sürümü, bu sorulara doğrudan cevap veren önemli Flow yenilikleri getiriyor. Bu yazıda, admin ve geliştirici ekiplerin günlük işini en çok etkileyecek değişiklikleri dört başlık altında inceliyoruz: test, düzen, Screen Flow deneyimi ve güvenlik.
1. Test Mode ve Kaydederken Hata Yakalama
Flow Builder'da Test Mode (Beta)
Yeni Test Mode, eski Debug ve test ekranlarının yerini alıyor. Debug ile test tek bir arayüzde birleşiyor ve testler kaydedilip daha sonra tekrar çalıştırılabiliyor.
- Tekrarlanabilirlik: Her değişiklikten sonra aynı senaryoyu elle yeniden kurmak yerine kayıtlı testi çalıştırmak yeterli.
- Regresyon Kontrolü: Karmaşık record-triggered flow'larda bir dala yapılan değişikliğin diğer dalları bozup bozmadığını hızlıca görmek mümkün.
Kaydederken Yakalanan Hatalar
Flow Builder artık iki yaygın runtime hatasını kaydetme aşamasında uyarıyor:
- Eksik Zorunlu Alanlar: Record variable kullanan bir Create Records elementinde zorunlu bir alan atanmamışsa uyarı veriliyor.
- Alan Uzunluğu İhlalleri: Alana sığmayacak uzunlukta değer atanabilecek durumlar önceden işaretleniyor. Bu, özellikle "bazen çalışıp bazen hata veren" flow'ların en sık nedenlerinden biriydi.
Bu iki yenilik, hatanın kullanıcı tarafında değil geliştirme aşamasında yakalanmasını sağlıyor.
2. Düzen ve Takip: Büyüyen Org'larda Flow Yönetimi
Onlarca, hatta yüzlerce flow'un bulunduğu org'larda asıl zorluk yeni flow yazmak değil, mevcutları anlamak ve yönetmek. Winter '27 bu alanda dört pratik araç getiriyor:
| Özellik | Ne Sağlar? |
|---|---|
| Flow Tags | Flow'lar Tag Category'ler altında etiketlenir; örneğin nesneye veya "Subflow" gibi türe göre sınıflandırma yapılabilir. |
| Element Gruplama | Flow içindeki bölümler başlık ve açıklamayla gruplanabilir, açılıp kapatılabilir. |
| Edit History | Her kaydın zaman çizelgesi görülür, eski sürümler geri yüklenebilir, element bazında değişiklikler incelenebilir. |
| Kullanılmayan Kaynak Filtresi | Artık kullanılmayan veya açıklaması eksik değişkenler ve kaynaklar listelenir. |
- Devir Teslim Kolaylığı: Gruplama ve kullanılmayan kaynak filtresi, bir flow'u başka bir ekip üyesine devrederken "bu değişken ne işe yarıyor?" sorusunu büyük ölçüde ortadan kaldırıyor.
- Ekip İçi Standart: Flow Tags'in faydası, ekip olarak ortak bir etiketleme standardı belirlendiğinde ortaya çıkar. Etiket kategorilerini baştan kararlaştırmak önemli.
Ayrıca End elementleri artık flow'un XML metadata'sına kaydediliyor. Bu, flow'ların Flow Builder dışındaki araçlarla (örneğin AI destekli geliştirme araçlarıyla) incelenmesini ve düzenlenmesini kolaylaştırıyor.
3. Screen Flow Deneyiminde Beklenen İyileştirmeler
List View ve Related List'ten Çoklu Kayıt İşleme
Artık bir Flow Quick Action, List View'a veya Related List'e eklenerek birden fazla kayıt üzerinde toplu işlem yapılabiliyor. Seçilen kayıtların Id'leri flow'a ids adında bir metin koleksiyonu olarak geliyor. Daha önce bu tarz toplu işlemler için LWC veya Visualforce tabanlı geçici çözümler geliştirmek gerekiyordu.
Quick Action Modal Boyutu
Screen Flow'u Quick Action ile çağırırken açılan pencerenin boyutu artık seçilebiliyor. Çok alanlı formların dar bir modal içine sıkışması, kullanıcılardan en sık gelen şikâyetlerden biriydi.
Reaktif Formüllerle Koşullu Görünürlük
Aynı ekrandaki bir bileşene referans veren reaktif formüller, koşullu görünürlük (conditional visibility) kurallarında artık doğru değerlendiriliyor. Bu sayede kullanıcının girdiği değere göre aynı ekranda alan gösterme/gizleme senaryoları, ek ekran veya karar elementi eklemeden kurulabiliyor.
4. Güvenlik: Kullanıcı Yetkilerini Her Durumda Uygulamak
Flow'larda "System Context" ile "User Context" arasındaki fark, özellikle flow başka bir flow'dan veya Apex'ten çağrıldığında karışıklığa yol açabiliyordu. Winter '27 ile autolaunched ve screen flow'lar için yeni bir çalışma modu geliyor: User Context – Enforces User Permissions.
- Ne Yapar? Flow nasıl çağrılırsa çağrılsın, yalnızca çalıştıran kullanıcının erişebildiği verilere erişir ve yalnızca onun yapabildiği işlemleri gerçekleştirir.
- Nerede Kullanılmalı? Experience Cloud kullanıcılarına veya geniş bir kullanıcı kitlesine açılan screen flow'lar, en çok fayda sağlanacak senaryolar.
Bu ayar, sürümdeki diğer güvenlik değişiklikleriyle aynı yönde ilerliyor. Örneğin Winter '27 ile Profile Filtering zorunlu hale geliyor; kullanıcılar "View All Profiles" yetkisi olmadıkça yalnızca kendi profillerini görebiliyor. Least Privilege (en az yetki) prensibini uygulayan ekipler için bu değişiklikler birlikte değerlendirilmeli.
Sonuç
Winter '27, Flow'u yalnızca "kod yazmadan otomasyon kurma aracı" olmaktan çıkarıp test edilebilir, versiyonlanabilir ve yönetilebilir bir platform bileşenine dönüştürüyor. Flow Builder artık Salesforce Cosmos temasıyla SLDS 2 görünümüne de kavuşuyor. Ekip olarak öncelikle şu adımları öneriyorum:
- Test Mode'u sandbox'ta kritik record-triggered flow'lar üzerinde deneyin.
- Flow Tags için ortak bir kategori ve etiket standardı belirleyin.
- Geniş kullanıcı kitlesine açık screen flow'ların çalışma modunu gözden geçirin.
- Çoklu kayıt işleme için yazılmış özel çözümleri listeleyip yeni Screen Flow özelliğiyle değiştirilip değiştirilemeyeceğini değerlendirin.
