Ümit Kara | Dynamics 365, Power Platform ve SharePoint Üzerine Notlar paylaşımnoktası
Dynamics365 · 14 Ağustos 2026 · 7 dk okuma

Business Rule mu, JavaScript mi? Dynamics 365’te Doğru Seçimi Yapmak

Dynamics 365’te form üzerinde bir alanı göstermek, gizlemek, zorunlu hale getirmek ya da basit bir kontrol yapmak istediğimizde genellikle iki seçeneğimiz oluyor: Business Rule veya JavaScript.

İlk bakışta ikisi de aynı işi yapıyor gibi görünebilir. Hatta çoğu durumda “Bunu JavaScript ile de yaparım, Business Rule ile de” demek mümkün. Ancak seçim yaparken konu sadece kod yazıp yazmamak değil. Kuralın nerede çalışacağı, hangi durumlarda devreye gireceği ve ileride kim tarafından yönetileceği de önemli.

Ben Dynamics 365 projelerinde bu ikisi arasında seçim yaparken özellikle birkaç noktaya dikkat ediyorum.

Önce kapsam konusuna bakmak gerekiyor

Business Rule oluştururken kapsam (Scope) seçimi, düşündüğümüzden daha önemli.

Bir Business Rule oluşturduğunuzda kuralın Entity veya Form kapsamında çalışmasını seçebiliyorsunuz.

Entity kapsamı seçildiğinde kural sadece form üzerinde çalışan bir yapı olarak kalmıyor. Kayıt oluşturma veya güncelleme işleminin farklı yollarında da devreye girebiliyor. Yani kullanıcı formu açmadan yapılan bir işlemde de Business Rule’un server-side tarafı çalışabiliyor.

Form kapsamı ise daha sınırlı. Kural sadece ilgili form üzerinde, client-side olarak çalışıyor. Örneğin bir kayıt Web API üzerinden güncellendiğinde form açık olmadığı için bu Business Rule’un çalışmasını beklememek gerekiyor.

JavaScript tarafında ise durum daha net: JavaScript client-side çalışır. Form açılmadan JavaScript’in çalışması söz konusu değildir.

Dolayısıyla server-side tarafta aynı kontrolü JavaScript ile yapmak istiyorsanız artık plugin gibi başka bir yapıya ihtiyacınız olur.

Burada önemli bir nokta var:

Veri tutarlılığını sadece form üzerinde değil, API, import gibi farklı giriş noktalarında da sağlamak istiyorsanız Entity kapsamındaki bir Business Rule ciddi bir avantaj sağlayabilir.

Aynı mantığı JavaScript ile çözmeye çalıştığınızda ise bunu ayrıca server-side tarafta da ele almanız gerekir. Bu da aynı iş mantığının iki farklı yerde tutulması ve dolayısıyla bakım yükünün artması anlamına gelir.

Business Rule ne zaman daha mantıklı?

Yapmak istediğiniz işlem basitse, ilk bakacağım yer Business Rule olur.

Örneğin:

  • Bir alana göre başka bir alanı göstermek veya gizlemek
  • Bir alanı zorunlu ya da opsiyonel hale getirmek
  • Bir alanı kilitlemek veya tekrar kullanılabilir hale getirmek
  • Bir alana varsayılan değer vermek
  • İki veya birkaç alan arasında basit bir koşul oluşturmak

Örneğin “Müşteri tipi X ise Vergi Numarası alanı zorunlu olsun” gibi bir kural için JavaScript yazmak çok hızlı ve gerçekçi bir çözüm değil.

Business Rule bunu zaten yapabiliyor. Üstelik sonradan bu kuralı değiştirecek kişinin JavaScript bilmesine de gerek kalmıyor.

Özellikle CRM’i sadece geliştiricilerin değil, admin veya power user’ların da yönettiği ortamlarda bu önemli bir avantaj.

Peki ne zaman JavaScript?

İş biraz daha karmaşık hale geldiğinde JavaScript’in avantajı ortaya çıkıyor.

Örneğin:

  • Birden fazla koşulun iç içe geçtiği bir yapı varsa
  • Daha karmaşık string veya veri işlemleri yapılacaksa
  • Döngü kullanmanız gerekiyorsa
  • Web API üzerinden başka kayıtları sorgulamanız gerekiyorsa
  • Form notification göstermek istiyorsanız
  • Tab veya section gibi Business Rule ile yönetemediğiniz alanlara müdahale edecekseniz

Burada Business Rule’un sınırlarına daha hızlı geliyorsunuz.

Özellikle Web API konusu önemli. Business Rule ile gidip başka bir tablodaki kaydı sorgulayamıyorsunuz. Böyle bir ihtiyacınız varsa JavaScript tarafında Web API kullanmanız gerekiyor.

Aynı şekilde kullanıcıya özel bir uyarı göstermek veya formun belirli bir bölümünün davranışını değiştirmek istediğinizde JavaScript çok daha esnek.

Bir başka konu da performans.

Entity kapsamındaki Business Rule server-side çalıştığı için özellikle çok sayıda kaydın işlendiği import gibi senaryolarda bunun yaratacağı yükü hesaba katmak gerekiyor. Binlerce kaydın içeri aktarıldığı bir senaryoda her kayıt için server-side bir Business Rule’un devreye girmesi göz ardı edilecek bir konu değil.

İkisini birlikte kullanmak da gayet normal

Bence burada “Business Rule mu, JavaScript mi?” sorusunu biraz yanlış sormak da mümkün.

Çünkü her şeyi JavaScript ile yapmak zorunda değiliz.

Örneğin bir formda:

Müşteri tipi = Kurumsal → Vergi Numarası zorunlu

gibi basit bir kural varsa bunu Business Rule ile çözmek daha mantıklı.

Ama aynı formda:

Müşteri tipi = Kurumsal → ilişkili kayıtları Web API ile kontrol et → sonuca göre kullanıcıya bildirim göster → belirli bir bölümü aç/kapat

gibi bir ihtiyaç varsa artık JavaScript kullanmak daha doğru olacaktır.

Yani Business Rule’un yapabildiği basit işleri JavaScript’e taşımak, ilk başta daha esnek görünse de uzun vadede gereksiz kod ve bakım yükü oluşturabiliyor.

Gözden kaçabilecek birkaç nokta

Business Rule ve JavaScript’i birlikte kullandığınız projelerde birkaç konuya özellikle dikkat etmek gerekiyor.

İlk olarak çalışma sırasına fazla güvenmemek lazım.

Business Rule’ların ve form olaylarının hangi sırayla çalıştığı konusunda varsayım yaparak bir yapı kurmak ileride sorun çıkarabilir. Özellikle aynı alanı hem Business Rule hem de JavaScript değiştiriyorsa bunu gerçek ortamda test etmek önemli.

Bir diğer konu Business Rule’u geçici olarak devre dışı bırakmak.

Örneğin belirli bir entegrasyonda Business Rule’un çalışmasını istemiyorsanız bunu JavaScript’teki gibi kolayca bir koşulla devre dışı bırakmak mümkün değil. Kuralı devre dışı bırakmak gibi seçenekler ise herkesi etkileyebilir.

Bu yüzden senaryoları baştan düşünmek gerekiyor.

Toplu veri aktarımı konusu da önemli.

Entity kapsamındaki Business Rule’lar toplu veri işlemlerinde devreye girebildiği için binlerce kaydın işlendiği importlarda performans etkisi yaratabilir. Büyük veri taşıma operasyonlarında bunu hesaba katmak gerekiyor.

Bir de ALM ve versiyonlama tarafı var.

JavaScript dosyalarını source control altında tutmak, Git üzerinden değişiklikleri takip etmek ve code review yapmak daha kolay. Business Rule tarafında ise aynı seviyede bir kod karşılaştırması yapmak mümkün olmadığı için özellikle büyük projelerde yönetim tarafı farklılaşıyor.

Sonuç olarak hangisini seçmeli?

Benim için karar verirken temel olarak şu sorular yeterli oluyor:

Basit bir alan davranışı mı?
→ Önce Business Rule’a bakarım.

Web API, döngü veya daha karmaşık bir mantık mı gerekiyor?
→ JavaScript.

Kuralın API, import gibi farklı giriş noktalarında da uygulanması mı gerekiyor?
→ Entity kapsamındaki Business Rule veya server-side plugin.

Kodun Git üzerinden yönetilmesi, code review ve test süreçleri önemli mi?
→ JavaScript daha avantajlı olabilir.

Binlerce kaydın işlendiği bir import senaryosu mu var?
→ Entity kapsamındaki Business Rule’u kullanmadan önce performans etkisini değerlendirmek gerekir.

Özetle, “JavaScript daha güçlü, o yüzden her şeyi JavaScript ile yapayım” yaklaşımı bana çok doğru gelmiyor. Business Rule’un çözebildiği basit bir problemi kodla çözmek yerine Business Rule kullanmak çoğu zaman daha temiz bir yapı ortaya çıkarıyor.

Diğer taraftan Business Rule’un sınırlarına geldiğiniz noktada da JavaScript’ten kaçınmanın pek bir anlamı yok.

Doğru yaklaşım bence ikisinden birini seçmek değil, ihtiyaca göre ikisini doğru yerde kullanmak.

Bu yazı işine yaradıysa paylaş
LinkedIn'de paylaş
SONRAKİ YAZI Dynamics 365’te Xrm.WebApi ile Temel Kayıt Sorgulama