Bu rehberi bitirdiğinizde üç farklı CRM yüzeyini birbirine karıştırmadan kurabileceksiniz: müşteriye giden belgeyi (e-posta, teklif, sözleşme), kayıt anında hatalı veriyi durduran kuralı ve ekibin gün boyu baktığı ekranı (Canvas). Bunlar Zoho'da ayrı menüler altında dursa da pratikte birbirini besler; yanlış sırayla kurulursa da birbirini sabote eder — örneğin bir doğrulama kuralı, kaydı aynı anda güncelleyen bir iş akışıyla sessizce devre dışı kalabilir. Aşağıda her bileşeni hangi sürümde açıldığı, hangi sayısal sınıra çarptığı ve butik klinik / KOBİ gibi gerçek bir akışta nereye oturduğuyla birlikte ele alıyoruz. Amacımız özellik tanıtmak değil; "bu yüzeyi sizin sürecinize nasıl doğru kurarız" sorusuna cevap vermek.
Üç Katman: Belge, Kural, Ekran
Bu rehberin kapsadığı üç bileşen aynı verinin üç farklı anına denk gelir. Bir kayıt önce girilir (kural burada devreye girer), sonra ekipçe okunur ve yönetilir (Canvas ekranı), en sonunda da müşteriye giden bir belgeye dönüşür (şablon). Hangi bileşeni ne zaman açacağınızı bu sıralama belirler; tasarıma ekrandan değil, kuraldan başlamak neredeyse her projede daha az geri dönüş üretir.
Kural — giriş anı
Doğrulama kuralları: geçersiz değer kaydedilmeden durdurulur ya da uyarıyla geçilir. Sadece manuel girişte çalışır; içe aktarma/API'yi denetlemez.
Ekran — yönetim anı
Canvas: ana sayfa, liste, kayıt detayı ve kayıt formu yüzeylerini markaya ve role göre yeniden çizer. Veri modelini değil, sunumu değiştirir.
Belge — çıktı anı
E-posta, Stok ve Mail Merge şablonları: kayıttaki alanları teklife, faturaya, onam formuna ve bilgilendirme mailine birleştirme alanlarıyla döker.
Butik bir estetik klinikte bu üç katman tek bir hasta yolculuğunda zincirlenir: danışman yeni hastayı açarken doğrulama kuralı telefonun +90 formatında olmasını dayatır; klinik yöneticisi gün içi randevuları Canvas liste görünümünde renk kodlu tile'lar hâlinde izler; tedavi onaylandığında da bilgilendirme/onam belgesi bir Mail Merge şablonundan hasta adına üretilir. Üç ayrı ayar gibi görünen şey, aslında tek bir sürecin üç durağıdır.
Bu yüzeyler farklı sürüm ve yetki ister. Doğrulama kuralları ile Canvas yüzeyleri Modül Özelleştirme / Özelleştirme Yönetimi (Manage Customization) profil yetkisi gerektirir. Canvas Ana Sayfa Standard ve üzeri; Canvas Liste/Detay/Form ve fonksiyon tabanlı doğrulama ise pratikte ücretli sürümlerde açıktır. Mail Merge yalnızca Professional, Enterprise, Ultimate sürümlerindedir. Projeye başlamadan sürümünüzü ve kim hangi yetkiye sahip onu yazılı netleştirin; kesin taahhüt öncesi lisans/veri merkezi (DC) kontrolü şart.
E-Posta Şablonları
E-posta şablonu, aynı mesajı her seferinde elle yazmadan — ama her alıcı için kişiselleşmiş hâlde — göndermenin yoludur. Tekil mailden toplu maile, otomatik yanıttan iş akışı bildirimine kadar Zoho içinde on üç ayrı yerde kullanılır. Üretim yeri sabittir: Kurulum > Özelleştirme > Şablonlar > E-Posta, ardından + Yeni Şablon ve modül seçimi.
Üç oluşturma yolu
- Sıfırdan (Blank): Metin, görsel, buton, sütun ve tablo bileşenlerini sürükle-bırak tasarımcıyla dizersiniz.
- Hazır galeri: Tüm Zoho dillerinde sunulan ön tasarımı seçip masaüstü/mobil önizlemeyle uyarlarsınız.
- HTML ekleme: "HTML kodu / düz metin ekle" bağlantısından kendi kodunuzu yapıştırırsınız — kurumsal kimliği piksel piksel korumak gerektiğinde tercih ettiğimiz yol budur.
Birleştirme alanları (merge fields)
Metin alanına # yazınca alan listesi açılır; örneğin ${Leads.First Name} her alıcının adını otomatik yerleştirir. Bir özel alan silindiğinde, modülle ilgisiz bir alan kullanıldığında veya bağlı entegrasyon (Google Ads, Ziyaretçi Takibi) kapatıldığında ilgili alan kırmızı işaretlenir. Bu kırmızı alanlar konu satırında, gövdede ve alt bilgide görünebilir; gönderim öncesi hepsini temizlemek gerekir.
Bir şablon en fazla 200.000 karakter taşır. Ek olarak en çok 10 dosya / toplam 3 MB eklenebilir. Şablon adı 75, konu satırı 150 karakterle sınırlıdır. Şablonlar modüle özgüdür: Müşteri Adayları (Leads) için yaptığınız şablonda Kişiler (Contacts) alanlarını birleştiremezsiniz. Bir alt formu tabloya dönüştürürken şablon başına en fazla 5 alt form tablosu eklenebilir ve bu tablolar klonlanamaz.
Şablonları klasörlerle düzenleyebilir, Analytics sekmesinden açılma/tıklanma oranını izleyebilir, modüller arası klonlayabilirsiniz. İş akışı, makro, onay süreci veya Blueprint'e bağlı bir şablon doğrudan silinemez — önce tüm ilişkilerinden çözmeniz gerekir. Varsayılan klasörler (Tüm Şablonlar, Favoriler, İlişkili Şablonlar, Benim oluşturduklarım, Benimle paylaşılanlar) silinemez veya özelleştirilemez.
Stok Şablonları ve PDF Geçişi
Stok (Inventory) şablonları, satışın resmî çıktılarını basar: Teklif (Quotes), Satınalma Siparişi, Satış Siparişi ve Fatura. Logo konumu, alanlar ve kalem satırları sürükle-bırakla düzenlenir; üretim yeri Kurulum > Özelleştirme > Şablonlar > Stok'tur. Şablonun maksimum genişliği standart PDF genişliğine eşittir, adı en fazla 75 karakter'dir. Her belge tipi yalnızca kendi modül grubundan alan çeker — örneğin Teklif şablonu Quotes, Products, Accounts, Contacts, Potentials ve özel modüllerden; Satınalma Siparişi ise Accounts yerine Vendors (Tedarikçiler) modülünden.
Eski PDF üreticisini kullanan organizasyonların HTML stok şablonlarını yeni biçime taşıması gerekir; Zoho bu kullanıcıları Stok Şablonları sayfasındaki uygulama-içi banner ile uyarır. Son tarih 31 Mart 2026; eski üretici bu tarihten sonra yaklaşık bir ay daha yedek olarak kalıp kaldırılır.
Geçişin gerçek mekaniği
Eski yapıda başlık/altbilgi tek bir <table> içindeki <thead>/<tbody>/<tfoot> bloklarındaydı. Yeni motor bunu üç ayrı <section> bloğu ister:
| Öğe | Eski (desteklenmeyen) | Yeni (desteklenen) |
|---|---|---|
| Başlık | <thead> tablo içinde | #header-container > #pdfgen-header |
| Altbilgi | <tfoot> tablo içinde | #footer-container > #pdfgen-footer |
| Sayfa no. | .pagenum + counter CSS | .pageNumber ve .totalPage |
Yalnızca .pagenum sayaç CSS'i kaldırılır; font, renk, tablo ve boşluk için yazılmış diğer tüm CSS korunur. Yeni motor sayfa numarasını otomatik basar. İçerikteki veri tabloları (ürün/kalem satırları) olduğu gibi kalır — yalnızca en dıştaki yerleşim tablosu değişir. Yönetici, taşıma sonrası Stok Şablonları sayfasındaki Proceed to Migration düğmesine basar.
Hizalama bozulursa Legacy PDF üreticisine geçip karşılaştırın; beklenmedik boşluk kalırsa html{margin:0;padding:0} ekleyin. Sınıf adının pageNumber (büyük N) olduğunu, birden çok header/footer-container bulunmadığını ve <tr>/<td> etiketlerinin tablo dışında kalmadığını doğrulayın. Eksenium olarak bu tür geçişlerde tek bir şablonu taşıyıp gerçek bir kayıttan PDF üretmeden hiçbir şablonu toplu güncellemiyoruz.
Mail Merge ile Belge Üretimi
Mail Merge, CRM verisini Zoho Writer üzerinde hazırlanmış bir şablona dökerek sözleşme, onam formu, resmî yazı, etiket veya zarf gibi belgeler üretir. E-postadaki mantığın aynısıyla belgeye birleştirme alanları yerleştirirsiniz; birleştirme anında her kayıt için doğru değerler dolar. Veriyi Leads, Accounts, Contacts, Potentials, Quotes, siparişler, faturalar ve özel modüllerden çekebilirsiniz. Üretim yeri Kurulum > Özelleştirme > Şablonlar > Mail Merge'dir.
| Konu | Sınır / Detay |
|---|---|
| Sürüm uygunluğu | Professional, Enterprise, Ultimate |
| Aylık birleştirme | 1.000 / ay / org (varsayılan) |
| Günlük üst sınır | 1.000 birleştirme (tüm sürümler) |
| Ek satın alma | 0,05 $ / birleştirme · min 500, maks 4.000 |
| E-posta ile gönderim | Günde maks 1.000 birleştirilmiş e-posta / org |
| Dinamik tablo | Alt form + ilgili liste toplam maks 3 / şablon |
Belgeye görsel ekleyebilir; alt formları tablo olarak (en çok 10 alan) ve ilgili liste kayıtlarını tablolaştırabilirsiniz — ancak birleştirme sonrası ilgili listeden yalnızca ilk 100 kayıt çekilir. Hazır MS Word ve PDF şablonlarını içe aktarabilirsiniz. Bu limitler 1 Kasım 2020'den beri geçerlidir.
Şablon tasarımına başlamadan tarayıcınızın açılır pencere engelleyicisini kapatın; Writer ayrı pencerede açıldığı için aksi halde tasarım ekranı yüklenmez. Gönderilen belgeleri kaydın E-postalar ilgili listesinden (alıcı bazlı) veya Writer'daki Tools > Mail Merge > View Mail Merge Logs'tan (şablon bazlı; In Progress / Completed / Failed) takip edersiniz.
Türkiye bağlamında Mail Merge'in en sık başvurduğumuz kullanımı klinik onam/aydınlatma formları ve KVKK açık rıza metinleridir: hastanın adı, tarihi ve tedavi bilgisi birleştirme anında doğru belgeye akar, ekip metni elle düzenlemez — bu hem hız hem de hukuki tutarlılık sağlar.
Doğrulama Kuralları
Doğrulama kuralı, hatalı verinin kayda girmeden önce yakalanmasını sağlar: kullanıcı geçersiz değerle kaydetmeye çalıştığında sistem ya engeller ya da uyarı gösterir. Kurallar alana ve düzene özgüdür — aynı alana farklı düzenlerde farklı kurallar tanımlayabilirsiniz. Erişim yolu: modül üzerinde (...) > Doğrulama Kuralları, veya Kurulum > Özelleştirme > Modüller ve Alanlar > [Modül] > Validation Rules.
Dört yapılandırma ekseni
Doğrulama tercihi
Hata ile durdur: geçersiz değerle kayıt engellenir. Uyarı ile izin ver: kullanıcı onayladıktan sonra kayda izin verilir, uyarı gösterilir. Tercih yalnızca "Save only" için geçerlidir.
Hata konumu
Birincil alanın yanında veya sayfa üstünde toplu. Hata konumu yalnızca tercih "hata ile durdur" iken erişilebilir.
Doğrulama anı
Save only: kaydet'e basınca tüm kurallar aynı anda tetiklenir. Field verify and save: önemli alanı erkenden doğrular; ancak Canvas Form görünümünde çalışmaz.
Doğrulama tipi
Kritere göre görsel oluşturucu veya fonksiyona göre Deluge ile karmaşık mantık. Fonksiyon tabanlı kurallar tercih/konum seçenekleriyle uyumlu değildir.
Kritere dayalı bir kuralda kural başına 10 birincil koşul, her birincil koşula 5 ikincil koşul ve her ikincil koşula 5 kriter tanımlanabilir; hata mesajı her koşula göre özelleştirilir. Bir KOBİ örneğinde "İskonto > %15 ise: Bu indirim onaylanamaz" kuralı temsilciyi %20 yazarken durdurur. Kurallar mobil uygulamada da çalışır, ama yalnızca masaüstünden oluşturulur.
Doğrulama kuralları yalnızca manuel giriş sırasında çalışır. Aynı alan içe aktarma, iş akışı, onay süreci, Blueprint, API veya web formu ile güncellenirse alan güncellemesi kuralı geçersiz kılar; Blueprint, kayıt süreç içindeyken kendi doğrulamasını kurala dayatır. Ayrıca kuralda kullanılan birincil alan toplu güncellemede listelenmez, ama ikincil alan toplu güncellemeye açık kalır — yani bölge bazlı indirim kuralında "Bölge" alanını toplu değiştirmek geçersiz veri üretebilir. Bir alanı güncellemeden önce bir kurala bağlı olup olmadığını kontrol edin.
Çoklu seçim arama, çoklu seçim listesi, çoklu kullanıcı, formül, otomatik numara, görsel yükleme ve çok satırlı alanlar doğrulama kapsamı dışındadır. Web formundan gelip kurala takılan kayıtlar otomatik reddedilmez; manuel onaya düşer.
Fonksiyon Tabanlı Doğrulama
Kritere dayalı kurallar "büyüktür/küçüktür" gibi karşılaştırmaları çözer; ancak desen (regex) ya da dış veritabanı kontrolü gerektiğinde Deluge fonksiyonuna geçilir. Tipik kullanım: telefon, IBAN, posta kodu, kimlik numarası gibi alanları belirli bir biçime zorlamak. Fonksiyon, kayıt verisini crmAPIRequest üzerinden okur, koşulu kontrol eder ve status ile message içeren bir yanıt döndürür.
Fonksiyon tabanlı doğrulamada Enterprise modül başına 3 kural, Ultimate 5 kural tanımlanabilir. Yalnızca kritere dayalı kuralların desteklediği alanlar burada da kullanılabilir; alan değerleri yalnızca API formatında gelir, bu yüzden alanın API adı kullanılmalıdır. Boş değer kontrolü eklenmezse fonksiyon hata verebilir.
Türkiye'ye uyarlanmış desen örnekleri
Zoho dokümanı UK/US/Hollanda gibi biçimler verir; biz aynı mantığı yerel ihtiyaca taşırız. Aşağıdaki desenler gerçek projelerde sık kurduğumuz türdendir (regex mantığı kaynaktaki örneklerle aynı, biçimler yerelleştirilmiştir):
- TC Kimlik (11 hane):
matches("[0-9]{11}")— 11 rakam değilse hata. - Türkiye IBAN:
matches("^TR[0-9]{24}")— TR + 24 rakam. (Kaynak Almanya içinDE[0-9]{22}kalıbını kullanır; yapı aynıdır.) - Türkiye cep telefonu:
matches("^\\+90-5[0-9]{2}-[0-9]{7}")— uluslararası biçim zorlaması. - Geçmiş tarih engeli: kapanış tarihi için
days360(today, closingDate.toDate()) > 0ile geriye dönük tarih girilmesini önlersiniz.
Fonksiyon, Kurulum > Developer Hub > Functions > +New Function altında "Validation Rule" kategorisiyle oluşturulup kurala bağlanır. Doğrulama mobil uygulamada da çalışır.
Canvas Yüzeyleri ve Görünüm Tipleri
Canvas, Zoho CRM'in standart "tablomsu" görünümünü markaya ve role göre yeniden çizmenizi sağlayan tasarım takımıdır. Önemli bir sınır: Canvas sunumu değiştirir, veri modelini değil — örneğin Canvas Ana Sayfa yalnızca giriş ekranını etkiler, modül verisine veya kayıtlara dokunmaz. Canvas dört ayrı yüzeyde çalışır ve her birinin kuralları farklıdır.
Ana Sayfa (Home View)
Role dayalı, aksiyon odaklı karşılama ekranı. Standard ve üzeri; org başına 50 Ana Sayfa görünümü. Dashboard, rapor, kiosk, widget, sorgu ve üç tip Canvas liste görünümü eklenir; sandbox'ta desteklenir.
Liste Görünümü (List View)
Üç tip: yatay özel liste, ızgara tile (okul/emlak için) ve renklendirilebilir tablo. Modül başına her tipten tek Canvas; ad modül içinde benzersiz olmalı.
Kayıt Detayı (Detail View)
Bölüm, sekme, tablo, görsel, ikon ve flex/grid ile detay sayfasını yeniden kurar. Özel modüller dahil tüm modüllerde; en fazla 5 arama (lookup) modülünden alan.
Kayıt Formu (Form View)
Logo, renk, font gibi marka öğeleriyle özel kayıt oluşturma formu. Tüm ücretli sürümlerde; alan durumu editörüyle dinamik görünürlük ve zorunluluk vurgusu.
Liste görünümü tipini senaryo belirler: bir okul öğrenci veritabanını tile görünümünde fotoğraflı kartlar olarak, bir emlak ofisi ilanları aynı şekilde, bir depo/stok ekibi ise tablo görünümünün elektronik tablo benzeri yapısında izler. Liste Canvas görünümünde sayfa başına en fazla 3 arama modülü kullanılabilir.
İstediğiniz düzenin görselini yükleyip Zia'nın eşleşen Canvas'ı otomatik kurmasını sağlayabilirsiniz; bu yetenek şu an tüm ücretli sürümlerde ve yalnızca US, EU, IN, JP, CN veri merkezlerinde açıktır. Türkiye kullanıcıları genellikle EU DC'de olduğundan erişilebilir; yine de kesin taahhüt öncesi DC kontrolü öneririz.
Canvas Detay Tasarımı ve Stil
Kayıt detayı, ekibin gün boyu en çok baktığı ekrandır; Canvas burada en çok değer üretir. Tasarımcı üç sütun mantığıyla çalışır — Veri (alanlar, ilgili modül alanları, ilgili listeler, bağlantılar, aksiyon düğmeleri ve kiosklar), Öğeler (Bölüm, Sekme, Tablo, Metin, Görsel, İkon, Çizgi, Flex, Field, List, Grid) ve Stil (font, arka plan, kenarlık, gölge, köşe yarıçapı, dolgu, kenar boşluğu, arka plan görseli). Üretim yolu: Kurulum > Özelleştirme > Canvas > Detail View > +Create Record Detail page, ardından Modül ve Düzen seçimi.
Düzeni canlandıran öğeler
- Sekme (Tabs): alanları ve ilgili listeleri ayrı ekranlara böler; Single expand ve Multi expand davranışını ve sekme başına benzersiz stili destekler.
- Flex: Vertical, Horizontal ve Wrap olmak üzere üç tip; responsive davranış, hizalama ve boşluk (Between/Evenly/Around) burada ayarlanır.
- Grid: dikdörtgen ızgaralar; breakpoint width ile belirli çözünürlüklerde responsive davranış kazanır.
- Field & List: değerleri sorgu (query) sonucuyla doldurulabilen alan ve liste öğeleri.
Her öğe sabit (fixed) ya da akışkan (fluid) işaretlenir: sabit, metni tanımlı uzunlukla sınırlar; akışkan, kullanıcının ekranına göre genişler. Önemli bir kısıt: en fazla 5 arama modülünden alan eklenir ve bu modüllerden Bölge (Territory), Görsel Yükleme ve Dosya Yükleme alanları Canvas'a alınamaz.
Stil tekrarını azaltan üç mekanizma vardır ve hepsi 25 ile sınırlıdır: öğe başına en fazla 25 özel CSS özelliği (Liste, Detay ve Form görünümlerinde geçerli), 25 preset stil ve 25 yeniden kullanılabilir bileşen (modüller arası taşınabilir). Hızlı Düzenleme (Quick Edit) açıldığında kullanıcılar alan değerine tıklayarak yerinde düzenleme yapar — ancak bu, o sayfadaki tüm alanlar için geçerli olur, tek alana sınırlanamaz.
Canvas Kuralları, Mobil ve Taşıma
Statik bir Canvas güzel görünür ama asıl değer, ekranın veriye göre değişmesinden gelir. Canvas Kuralları (koşullu stil) bir öğenin görünümünü bir alan değerine göre değiştirir — örneğin kapanış tarihi geçmiş anlaşmaları kırmızıya boyamak gibi. Kural, Canvas Builder içinde öğe seçilip + > Create Canvas Rule ile tanımlanır, koşul girilir, kaydedilip uygulanır; aynı kural başka öğelere yeniden uygulanabilir.
Mobil Canvas ayrı bir dünyadır
Web için tasarlanan Canvas sayfaları mobilde çalışmaz; mobil kayıt detayı, web uygulamasındaki özel mobil Canvas tasarımcısıyla kurulur (Canvas > Detail View > Mobile). Tek tasarım hem Android hem iOS'ta geçerlidir ama Android tablet ve iPad'de desteklenmez. Bir bileşen iki platformdan birinde yoksa sistem sizi uyarır; önizlemeyi Android ya da iOS sekmesinden yaparsınız. Kullanıcı mobilde kayda girip Switch View ile Canvas sayfasına geçer.
Bir Canvas tasarımını dışa aktarınca benzersiz bir anahtar üretilir: aynı anda en fazla 10 anahtar, her biri 7 gün geçerli. Kritik nokta: yalnızca arayüz öğeleri taşınır — alan değerleri, görseller ve Canvas kuralları aktarılmaz. Bu yüzden bir tasarımı sandbox'tan üretime taşırken kuralları ve görselleri hedef ortamda yeniden kurmanız gerekir; "export ettim, bitti" varsayımı eksik kuruluma yol açar.
Atama da profil bazlıdır: Canvas Assignment ile her profile farklı bir Canvas verebilirsiniz; bir Canvas'ı silmeden önce varsayılan atamasını kaldırmanız gerekir. Bir mobil/masaüstü Canvas yalnızca aktif olduğunda kullanıcıya görünür.
