Bir CRM kurulumunda en pahalı hatalar otomasyonda değil, veri modelinde yapılır. Yanlış tipte açılan bir alan, eksik kurulan bir ilişki ya da geç fark edilen bir mükerrer kayıt, üzerine yıllarca iş akışı ve rapor inşa edildikten sonra geri dönülmesi zor bir borca dönüşür. Bu rehber, alanları tek tek anlatan bir özellik listesi değildir; alanları bir veri modelinin yapı taşları olarak ele alır. Sonunda elinizde, hangi verinin nerede duracağına, neyle ilişkileneceğine ve nasıl güncel kalacağına dair Eksenium'un sahada kullandığı karar çerçevesi olur — böylece otomasyon sırası geldiğinde sağlam bir zemine kurulur.
Veri Modeli Otomasyondan Önce Gelir
Çoğu "otomasyon çalışmıyor" şikâyetinin altında aslında bir veri modeli sorunu yatar: iş akışının dayanacağı alan ya yanlış tipte, ya yanlış modülde, ya da değerleri tutarsız girilmiştir. Bu yüzden alan tasarımına geçmeden önce dört soruyu sırayla yanıtlamak gerekir. Bu sıralama, kurulum boyunca yön pusulanızdır.
Nerede
Bu veri hangi modülde doğuyor? Hastanın doğum tarihi Kişiler'de mi, randevu kaydında mı tutulmalı?
Neyle Bağlı
Bu veri başka hangi kayıtla ilişkili? Bir tedavi planı hastaya mı, anlaşmaya mı bağlanmalı?
Nasıl Güncellenir
Değer kim tarafından, hangi anda değişiyor? Elle mi, dönüşümle mi, API ile mi?
Ne Üretir
Hangi raporu süzecek, hangi otomasyonu tetikleyecek? Çıktı belliyse alanın tipi de bellidir.
Bu sorulara cevap vermeden açılan her alan, sonradan değiştirilmesi mümkün olmayan bir karardır. Zoho CRM'de bir alanın veri tipi oluşturulduktan sonra değiştirilemez; etiketi yeniden adlandırabilirsiniz ama "Metin" olarak açtığınız bir alanı "Sayısal" yapamazsınız. Veri tipi yanlışsa tek çare alanı silip yeniden açmak ve mevcut veriyi taşımaktır.
Free sürümde özel alan desteği yoktur; veri modelinizi gerçekten kurgulayacaksanız en az Standard gerekir. Modül başına alan sayısı ve belirli alan tiplerinin (renk, roll-up, dosya vb.) limitleri sürüme göre değişir. Kesin sayılar için taahhüt öncesi lisans/DC kontrolü yapın.
Veri Nerede Durur: Alan Tipi Kararı
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.
| Tip | Sınır | Filtre/Kriter | Ne zaman |
|---|---|---|---|
| Metin (tek satır) | 255 karakter | Var | Ad, kod, kısa serbest etiket |
| Çok satırlı – Küçük | 2.000 | Var (+ şifreleme) | Hassas kısa not |
| Çok satırlı – Büyük | 32.000 | Yok | Uzun açıklama |
| Zengin Metin (RTF) | 50.000 | Yok | Biçimli içerik (zorunlu yapılamaz) |
| Para Birimi | 16 hane | Var | Tutar, fiyat (4 yuvarlama seçeneği) |
| Otomatik Numara | Önek+başlangıç+sonek | Var | Dosya/kayıt no |
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.
Zengin Metin alanı güçlü görünür ama pahalıdır: alt formlarda, liste/kanban görünümünde, filtrede, formülde ve mobil uygulamada desteklenmez; zorunlu yapılamaz; Görevler ve Toplantılar'da 2, diğer modüllerde 5 alanla sınırlıdır. İçe aktarma/API'de yalnızca belirli HTML etiketleri (b, i, u, a, ul, ol, li, p, span, strong vb.) geçer. Veriyi sonradan süzecekseniz RTF değil, düz metin seçin.
Bütünlük: Zorunlu ve Benzersiz Alanlar
İ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.
| Kural | Detay |
|---|---|
| Benzersiz yapılabilen tipler | Metin, E-posta, Telefon, Tam Sayı, Uzun Tam Sayı, URL |
| Modül başına benzersiz alan | 2 (Adaylar/Kişiler/Özel modüller ve Ürünler'de 3) |
| Aktivite modülleri | Görevler, Aramalar, Toplantılar benzersiz alan alamaz |
| İndeksleme | İşaretlemeden sonra birkaç dakika sürebilir |
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.
Bir estetik klinikte aynı hastanın iki kez açılması, randevu ve tedavi geçmişini ikiye böler ve KVKK kapsamında veri tutarlılığını zorlaştırır. T.C. kimlik veya telefonu (E-posta/Telefon/Metin tipiyle) benzersiz işaretlemek, hem kayıt aşamasında hem içe aktarmada bu çoğalmayı engeller. Adaylar modülünde ayrıca "dönüştürülmüş adaylara karşı kontrol" açılabilir; böylece daha önce kişiye dönüşmüş biri tekrar aday olarak eklenmez.
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.
İlişkiler: Lookup, Mirror ve Çoklu Bağ
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.
Bu alanlar iki yönlü senkron yapmaz: üst kayıttaki değer değiştiğinde çocuk alan güncellenmez; değer yalnızca lookup kaydının kendisi güncellenince dolar. Ayrıca otomasyon/blueprint ile güncellenemez, "benzersiz" yapılamaz ve sistem alanları field of lookup olamaz. Canlı, eşzamanlı yansıma istiyorsanız aşağıdaki Mirror'a bakın.
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.
Tutarlılık: Genel Kümeler ve Bağımlılık
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.
| Sürüm | Küme/Org | Modül başına | İlişkilendirme |
|---|---|---|---|
| Enterprise | 30 | 15 | 30 |
| Ultimate | 50 | 15 | 30 |
Lead Status, Deals Stage, Salutation gibi bazı sistem listeleri genel kümeye bağlanamaz; çoklu seçim listeleri de şimdilik desteklenmez. Bir küme 15'ten fazla alana bağlıysa değer silemez/değiştiremez ve kümeyi silemezsiniz; kullanılmayandan kullanılana tek seferde en çok 50 değer taşıyabilirsiniz. Kümedeki bir değeri yeniden adlandırmak/değiştirmek, mevcut kayıtlar dahil iş akışları, kriterler ve raporlardaki değeri günceller.
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.
Türetilmiş Veri: Formül ve Özet Alanlar
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.
| İhtiyaç | Yaklaşım |
|---|---|
| Doğum tarihinden yaş | Year(Now()) − Year(DOB), ay/gün düzeltmesiyle |
| Seviyeye göre vade tarihi | İç içe If() + Adddate(başlangıç, gün, 'DAY') |
| Alanları birleştirip kod üretme | Concat(Tostring(...), Tostring(...)) |
| Açılır listeyi sayıya çevirme | Tonumber(...) — liste değerleri varsayılan olarak metindir |
Dönüş tipi oluşturduktan sonra değiştirilemez ve ifade en çok 5.000 karakter olabilir. Yeni formül alanı yalnızca eklendikten sonra oluşturulan kayıtlar için hesaplanır; mevcut kayıtlarda katkı veren alanlar düzenlenene kadar boş kalır. Now() yalnızca kayıt elle/otomasyonla güncellenince yenilenir; gerçek zamanlı yenileme ayrı ayar ister ve düzen başına en çok 2 oto-yenilenen alan olabilir (custom view/gelişmiş filtrede desteklenmez). Enterprise ve üzeri sürümlerde Zia Formül Üretici, ihtiyacı düz dille yazdığınızda ifadeyi üretip önizletir.
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.
Görünürlük: Durum, Kategori ve Geçmiş
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 "Randevu Bekliyor → Konsültasyon → Tedavi Planlandı → Tamamlandı / İ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.
Kayıt kategorisi Kullanıcılar, Teklifler, Faturalar, Satış ve Satınalma Siparişleri modüllerinde kullanılamaz; üstelik sistem içinde bir tarih/saat alanı oluşturarak özel alan kotanızdan harcar. Geçmiş takibinde izlenen alanı silmek/devre dışı bırakmak verinin kalıcı kaybına yol açar — sürüm düşürmeden önce yedek alın; lisans bitişiyle düşüşte ise verileriniz için tipik olarak 60 günlük bir koruma süresi tanınır.
Standart Modül Omurgası ve Aktiviteler
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.
| Modül | Zorunlu alanlar | Karakter / not |
|---|---|---|
| Müşteri Adayları | Soyad, Şirket | Soyad 80, Şirket 100; Ad 40 |
| Kişiler | Soyad | Soyad 40; Hesap Adı lookup ile bağlanır |
| Hesaplar | Hesap Adı | 100; Yıllık Gelir 16 haneli para birimi |
| Anlaşmalar | Anlaşma Adı, Hesap Adı, Kapanış Tarihi, Aşama | Anlaşma Adı 120; Beklenen Gelir otomatik |
| Vakalar | Konu, Durum, Vaka Kaynağı | Konu 255; Vaka No 16 haneli otomatik |
| Teklifler | Konu, Hesap Adı, Ürün, Adet, Birim/Liste Fiyatı | Konu 50; Şartlar yalnızca yeni kayıtta |
| Faturalar | Konu, Hesap Adı, Ürün, Adet, Birim/Liste Fiyatı | Fatura No 16 haneli otomatik |
| Ürünler | Ürün Adı | 50; Birim Fiyat para birimi |
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.
Görevler, Aramalar ve Toplantılar pek çok özelleştirmeyi desteklemez: lookup eklenemez, kullanıcı alanı ve benzersiz alan açılamaz, roll-up ve picklist geçmiş takibi çalışmaz, RTF 2 alanla sınırlıdır. Bu modüllere veri modelinizin ağırlığını yüklemeyin; ilişkisel veriyi ana modüllerde tutup aktiviteleri yalnızca eylem kaydı olarak kullanın.
Eksenium olarak kurulumda izlediğimiz sıra şudur: önce verinin nerede durup neyle bağlanacağını çiz (modül + lookup), sonra bütünlüğü kur (zorunlu + benzersiz), ardından tutarlılığı sağla (genel küme + bağımlılık), türetilebileni türet (formül + roll-up), görünürlüğü ekle (durum + kategori + geçmiş) ve en son otomasyonu bu zeminin üstüne kur. Bu sıra, manifestonun "veri modeli otomasyondan önemlidir" ilkesinin sahadaki uygulamasıdır.
