Alanlar ve Veri Modeli

Alan tipi, verinin nasıl saklandığını ve daha sonra nasıl süzülebileceğini belirler. Aynı bilgiyi yanlış tiple tutmak, örneğin "şehir"i serbest metne yazmak, raporu kullanılamaz hâle getirir. Karar verirken iki şeyi aynı anda düşünün: verinin doğası ve verinin sonradan filtrelenip filtrelenmeyeceği.

Seçim tabanlı tipler veri kalitesinin en kritik kararıdır: açılır liste tek seçim, çoklu seçim birden çok değer, radyo düğmesi ise hepsi göz önünde duran az sayıda seçenek içindir. Radyo düğmesinde düzen başına en çok 3 görünür seçenek olabilir ve seti dışındaki değerler reddedilir, Evet/Hayır ya da öncelik düzeyi gibi sabit tercihler için idealdir. Açılır listede ise bir değeri yeniden adlandırdığınızda, o değer halihazırda kullanıldığı tüm kayıtlarda otomatik güncellenir.

İyi bir veri modeli sadece doğru veriyi toplamaz, yanlış veriyi de baştan engeller. Bunun iki ana aracı vardır: bir alanı zorunlu yaparak kaydın eksik bilgiyle oluşmasını önlemek, ve benzersiz (unique) işaretleyerek aynı değerin iki kez girilmesini engellemek. Benzersizlik, manuel oluşturma, içe aktarma, API çağrıları ve müşteri adayı/teklif dönüşümlerinde mükerrer kontrolünü tetikler ve büyük/küçük harfe duyarsız çalışır.

Zorunluluk dengelidir, abartısı zararlıdır. Manifesto duruşumuz nettir: kullanıcı sistem için çalışmamalı. On zorunlu alanlı bir form, temsilciyi kaydı yarım bırakmaya ya da uydurma veri girmeye iter. Yalnızca raporun ve dönüşümün gerçekten muhtaç olduğu alanları zorunlu yapın.

Tek satırlık metin alanları ayrıca Dış Alan (external field) olarak işaretlenebilir; bu, üçüncü parti sistemlerin kimliklerini saklayıp API ile upsert (varsa güncelle, yoksa oluştur) işlemine imkân verir. Dış kimlik kuruluş ya da kullanıcı temelli olabilir; yalnızca API ile güncellenir, klonlanan kayıtlara kopyalanmaz ve birleştirmede ana kaydın dış kimliği korunur. Bu, CRM'i dış muhasebe/randevu sistemine bağlarken kayıt eşlemesinin omurgasıdır.

Veri modelinin kalbi alanlar değil, alanlar arasındaki ilişkilerdir. Manifestonun "önce ilişkiler" ilkesi tam da burada işler. Modüller arası bağ kurmanın temel aracı lookup (arama) alanıdır: bir anlaşmayı bir hesaba, bir hastayı bir doktora bağlarsınız. Lookup üç limitle gelir: arama penceresinde en çok 10 alan gösterilir, kriterlerde en çok 5 lookup alanı kullanılabilir ve Görevler, Toplantılar, Aramalar'a lookup eklenemez.

İlişkiyi disipline eden iki katman

• Lookup Filtresi (Enterprise ve üzeri): Kullanıcının yalnızca geçerli kayıtları seçebilmesini sağlar. Değer tabanlı (örn. yalnızca "Sektör = Teknoloji") ya da alan tabanlı (örn. kişinin şehriyle eşleşen hesaplar) olabilir. Anlaşma açarken yalnızca aktif hesapları listelemek, hatalı eşleşmeyi kaynağında keser.
• Lookup Alanından Ek Alanlar / Field of Lookup (Enterprise ve üzeri): Birincil bağın ötesindeki detayları da getirir, kişinin e-postası, telefonu, sorumlusu Anlaşmalar'da yan yana görünür ve rapora girer. En çok 5 alan eklenebilir.

Mirror: ilişkiyi taşımadan göstermek

Mirror Bileşeni salt-okunur bir penceredir: ilişkili kayıttaki bilgiyi gerçek zamanlı olarak mevcut kaydın içinde gösterir. Temsilci, tek bir müşteri sorusu için Anlaşma-Kişi-Hesap-Ürün arasında gezinmek zorunda kalmaz. En kritik avantajı veri modeli açısındandır: Mirror alanı kopyalamadığı için alan limitini, Raporları, İş Akışlarını ve otomasyonları etkilemez.

• Modül başına en çok 100 mirror alan, en fazla 5 lookup alanı üzerinden.
• Yalnızca oluşturma, düzenleme ve detay sayfalarında görünür; liste görünümlerinde yer almaz.
• Kriter ve filtrelerde kullanılamaz, bunun yerine özel görünümde modüller-arası filtre kurun.
• Lookup bağı kaldırılınca mirror alanlar kaybolur; yeni kayıt seçiminde anında güncellenir.

Çok-çok ilişkiler için Çoklu Seçim Lookup (Enterprise ve üzeri) kullanılır: bir poliçe birden çok sigortalıya, bir sigortalı birden çok poliçeye bağlanabilir. Modelinizde "bir kayıt birden çok kayda bağlanmalı" durumu varsa, tek lookup'ı zorlamak yerine bu tipi tercih edin.

Aynı seçeneklerin birden çok modülde tekrar etmesi, veri modelinin sessiz bir tutarlılık sorunudur. "Müşteri Kaynağı" değerleri Adaylar, Kişiler ve Anlaşmalar'da ayrı ayrı tutuluyorsa, biri güncellenip diğeri unutulduğunda raporlar bölünür. Genel Kümeler (Global Sets) bu sorunu kökten çözer: değer setini bir kez kurar, birden çok listeye bağlarsınız; kümede yaptığınız değişiklik bağlı tüm listelere yayılır.

Erişim Modules Customization yetkisiyle, Kurulum > Özelleştirme > Modüller ve Alanlar > Genel Kümeler yolundan sağlanır. Üç yolla oluşturulur: sıfırdan, mevcut yerel listeyi dönüştürerek veya bir kümeyi klonlayarak.

Bağımlı Alan Eşlemesi (Map Dependency Fields)

Tutarlılığın ikinci katmanı, seçimler arasında mantık kurmaktır. Bağımlılık eşlemesi, seçim tabanlı alanlar arasında ebeveyn-çocuk ilişkisi kurar: "Departman = Satış" seçilince "Rol" listesinde yalnızca satış rolleri görünür. Düzende en az iki seçim tabanlı alan (açılır liste, çoklu seçim veya radyo) olmalı; çoklu seçim listeleri yalnızca çocuk alan olabilir, alt formdaki ebeveyn yalnızca aynı alt formdaki alana eşlenir. Eşleme Map Dependency Fields sekmesinden yapılır; 50'den az seçenekte açılır menüden, 50+ seçenekte Gelişmiş görünümle (aralık için Shift+tık) eşlersiniz.

Bir klinikte bunun pratik karşılığı şudur: "Şube" seçildiğinde yalnızca o şubedeki doktorlar, doktor seçildiğinde yalnızca o doktorun verdiği hizmetler listelenir. Böylece veri girişi hem hızlanır hem de imkânsız kombinasyonlar baştan engellenir.

Bazı veriler girilmez, hesaplanır. Doğum tarihinden yaş, "dosya alındı + 10 gün"den teslim tarihi, ilişkili kayıtların toplamından bir özet, bunları elle tutmak hem hataya açıktır hem de güncel kalmaz. İyi bir veri modeli, türetilebilir her veriyi türetir.

Formül Alanları

Formül alanı, başka standart/özel alanlardan dinamik değer üretir; kullanmak için profilde Field-level Access yetkisi gerekir. Üç yapı taşı vardır, fonksiyonlar (Abs(), Concat(), Adddate(), Now()...), argümanlar ve operatörler (+, *, %). Bir formül; Ondalık, Para Birimi, Metin, Tarih, Tarih-Saat veya Mantıksal (Boolean) sonuç döndürebilir.

Roll-up Özet Alanları

Roll-up özet, ilişkili listelerdeki değerleri tek bir kayda toplar: ilişkili kayıt sayımı, sayısal alanlarda Toplam/Ortalama/En Yüksek/En Düşük, tarih alanlarında En Erken/En Uzak/En Son/Yaklaşan. Bir hesabın altındaki tüm açık anlaşmaların toplam tutarını ya da bir hastaya ait tedavilerin sayısını kayıt içinde anlık görmek için kullanılır.

• Sürüm limiti: Enterprise 10, Ultimate 15 roll-up alan/modül.
• "En son"/"yaklaşan" fonksiyonlu özet alanlarında tüm modüller genelinde en çok 100 alan.
• Salt-okunurdur ve değer yalnızca kayıt kaydedildikten sonra hesaplanır.
• Görevler, Aramalar, Toplantılar ve Randevular'da kullanılamaz.

Manifesto sırasında görünürlük otomasyondan önce gelir: ölçemediğiniz süreci yönetemezsiniz. Açılır liste alanları, doğru üç özellikle donatıldığında basit bir seçim kutusundan bir durum yönetim panosuna dönüşür. Bunlar veriyi değiştirmez; mevcut veriyi okunur ve ölçülebilir kılar.

Renk Kodlama

Değere renk atayıp liste, kanban, grafik ve pipeline'da durumu tek bakışta okunur kılar. Modül başına 100 değere kadar renklenir; renkli alan sayısı Standard 2, Professional 5, Enterprise 10, Ultimate 15.

Kayıt Kategorisi

Detaylı değerleri "Açık / Başarılı / Başarısız" gibi üst gruplara eşler. Modül başına en çok 5 kategori; tek liste için açılır, 200 seçeneğe kadar destekler. Tüm ücretli sürümlerde var.

Geçmiş Takibi

Bir kaydın aşamalar arasında ne kadar kaldığını izler. Modül başına tek liste; 5 varsayılan alana 10 alan eklenir. Aramalar, Görevler, Toplantılar'da yok.

Somut akış: bir butik medikal klinikte Hasta Durumu listesi sırasıyla "Randevu Bekliyor", "Konsültasyon", "Tedavi Planlandı" ve son olarak "Tamamlandı" ya da "İptal" değerlerini taşır. Bunları "Açık / Başarılı / Başarısız" kategorilerine eşleyince yönetici her hastanın genel durumunu tek bakışta görür; renk kodlama kanban'da görsel ayrımı verir; geçmiş takibi ise "konsültasyondan tedaviye geçiş kaç gün sürüyor" sorusunu ölçer. Bu üçü kurulmadan otomasyon kurmak, görmediğiniz bir süreci hızlandırmaya çalışmaktır.

Veri modelini sıfırdan kurmazsınız; Zoho'nun standart modülleri hazır bir omurga sunar: Müşteri Adayları, Hesaplar, Kişiler, Anlaşmalar, Kampanyalar, Tahminler, Vakalar, Çözümler, Ürünler, Fiyat Kitapları, Teklifler, Faturalar, Tedarikçiler, Satınalma/Satış Siparişleri, Görevler, Aramalar ve Toplantılar. Her modülün zorunlu (mandatory) alanları, modelinizin değiştiremeyeceğiniz temelidir; bunları öğrenmeden özel alan tasarlamak boşa emektir.

Standart alan stratejisi tek cümleyle özetlenir: silmeye çalışmayın, gizleyin. Zorunlu sistem alanları düzenlenemez ya da silinemez; işinize yaramayan diğer standart alanları gizleyebilir, eksikleri özel alanla tamamlayabilirsiniz. Kaldırdığınız özel alan "Kullanılmayan Alanlar"a taşınır, verisiyle geri yüklenebilir; ama kullanılmayan alanlar bile sürüm limitinize sayılır, dolayısıyla kalıcı silmeden önce iki kez düşünün.

Eksenium olarak kurulumda izlediğimiz sıra şudur: önce verinin nerede durup neyle bağlanacağını çizeriz (modül + lookup), sonra bütünlüğü kurarız (zorunlu + benzersiz), ardından tutarlılığı sağlarız (genel küme + bağımlılık), türetilebileni türetiriz (formül + roll-up), görünürlüğü ekleriz (durum + kategori + geçmiş) ve en son otomasyonu bu zeminin üstüne kurarız. Bu sıra, manifestonun "veri modeli otomasyondan önemlidir" ilkesinin sahadaki uygulamasıdır.