Alanlar da Mimaridir

🌐 28 dilde daha mevcut

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Görsel yapay zekâ ile üretilmiştir

Yapay zekâ ile çevrildi. Henüz topluluk tarafından incelenmedi. İngilizcesini oku

Data Architect kursunun 3. bölümü olan Salesforce Veri Mimarisi bölümündeki 10 modülden 6.‘sı. Her modül kendi başına okunabilir. Önceki: Doğru Nesneyi Seçin · Sonraki: İlişkilerin Sonuçları Vardır

Bu modülün yanıtladığı soru: Salesforce her bir veri parçasını fiziksel olarak nasıl temsil etmeli?

Bir alan oluşturmak yaklaşık bir dakika sürer. Yeni Alan, bir tür seçin, adını verin, İleri, İleri, Kaydet. Alanların mimari olarak ele alınmamasının nedeni tam olarak bu.

On yıldır var olan bir org’a girin ve Hesap’ı açın. Beş yüz alan. Status2__c, Legacy_Status__c, Old_Status__c, Status_New__c. Üç farklı müşteri numarası. Hangi entegrasyonun hâlâ kullandığını kimse bilmediği için kimsenin silmeyeceği bir onay kutusu. Alanı oluşturmak bir dakika sürdü. Onunla yaşamak yıllar sürer. Dolayısıyla bu modülün fikri basit: bir alan mimari bir karardır. Her zaman büyük bir karar değildir, ama her alan verinin anlamı, davranışı, kimliği ya da kalitesi hakkında bir şey kodlar ve nesneler gibi alanların da eklenmesi kolay, kaldırılması şaşırtıcı derecede zordur.

Bu Veri Gerçekte Ne Anlama Geliyor?

2. bölümde varlıklarımıza öznitelikler verdik: bir Teslimat’ın planlanmış bir zaman aralığı, bir Kamyon’un bir şasi numarası vardır. Şimdi bunları uyguluyoruz ve insanların doğrudan “metin alanı”na atladığı yer burası. Bekleyin. Türden önce verinin ne anlama geldiğini bilmek isterim. Bir sayı mı, yoksa rakam içeren bir tanımlayıcı mı? Bir tarih mi, yoksa zamanda bir an mı? Serbest metin mi, yoksa onaylı bir kümeden bir değer mi? Bir kişi tarafından mı giriliyor, yoksa başka bir sisteme mi ait? Değişebilir mi? Benzersiz olmalı mı? Eksik olabilir mi? Hiç saklanmalı mı, yoksa hesaplanmalı mı? Bunlar Kurulum soruları değil. Veri mimarisi sorularıdır ve alan türü onları yanıtladıktan sonra gelir.

Bir Sayı Her Zaman Bir Sayı Değildir

Steve Trucking her kamyona bir filo numarası verir, diyelim 001247. Sayı alanı mı? Muhtemelen hayır. Filo numaralarını topluyor muyuz? 1247 numaralı kamyon eksi 1246 numaralı kamyon bir kamyon mu eder? Bu, rakam içeren bir tanımlayıcıdır ve bir Sayı alanı baştaki sıfırları bile atar. Posta kodları, ürün kodları, hesap numaraları ve takip numaraları için de aynısı geçerli. Değerin neye benzediği size ne anlama geldiğini söylemez. Türü örnek verinin neye benzediğine göre değil, ihtiyaç duyduğunuz davranışa göre seçin.

Bir İnsanın Onu Tanımlaması Gerekiyor mu?

Her özel nesne bir Ad (Name) alanı alır ve ilk karar metin mi otomatik numara mı olacağıdır. Sorarım: bir insanın bu şeyi tanımlaması gerekiyor mu? İnsanlar bir Perakende Ortağını adıyla, bir kamyonu filo numarasıyla bilir. Peki ya sistemin her gece ürettiği bir yük listesi? Salesforce bir Ad istedi diye kimse “Yük Listesi 10-02 Numara 3” yazmamalı. Ona bir otomatik numara verin. Yalnızca üretilen bu Adı kaydın kimliğiyle karıştırmayın: otomatik numara kullanıcılara yardım eder, Salesforce kimliği kaydı tanımlar ve Perakende Ortağının kendi yük listesi referansı aynı şeyi sistemler arasında tanımlayabilir. Üç farklı iş.

Ayrıntılar Ekranı

Bir tür seçin, İleri’ye tıklayın; Kurulum ayrıntıları sorar. Bu modüldeki kararların çoğunun gerçekten verildiği ekran budur, genellikle de aceleyle.

Yeni Özel Alan, 2. adım: ayrıntılar (ekran görüntüsü, 2026-10-12). Tam boyut

İki kutu birbirine benzer ama farklı işler görür. Açıklama (Description), org’un bakımını yapan insanlar ve artık onu okuyan yapay zekâ araçları içindir: alanın ne anlama geldiği, sahibinin kim olduğu, nereden geldiği. Yardım Metni (Help Text) ekrandaki kullanıcı içindir: buraya ne yazılacağı. İkisini de doldurun. Ardından Zorunlu, Benzersiz ve Harici Kimlik gelir ve her biri kendi bölümünü hak eder. Onların altında Varsayılan Değer bir formül olabilir; böylece yeni bir kayıt boş yerine mantıklı bir değerle başlayabilir.

Zorunlu, Göründüğünden Büyük Bir Karardır

Alan sihirbazında Zorunlu etiketli küçük bir onay kutusu var ve 1. bölümde gördüğümüz gibi saatli bir bomba olabilir. Beş yıldır bir nesneniz ve iki milyon kaydınız var ve şimdi biri yeni bir alanın her zaman bir değeri olması gerektiğine karar veriyor. Ondan önceki iki milyon kayıt ne olacak? Onu göndermeyen entegrasyonlar? Değer bilinmeden kaydı oluşturan otomasyon? Değerin ancak üç adım sonra ortaya çıktığı süreç?

“Zorunlu” bir veri kalitesi kararı gibi görünür ve bazen öyledir. Ama bir değerin ne zaman bilindiği iş sürecinin bir parçasıdır. Bu yüzden biri “onu her zaman isteriz” dedi diye Zorunlu’yu işaretlemeyin. Ne zaman bilindiğini, onu kimin sağladığını ve sağlanmadığında ne olacağını sorun. Bunu 7. modülde tam tutarlılık merdivenine yerleştireceğiz.

Benzersizin de Bir Anlamı Vardır

Bir alanı benzersiz olarak işaretlersem iş hakkında bir ifade kullanmış olurum: “genellikle tekrarlanmaz” değil, “iki kayıt asla bu değere sahip olamaz.” Bu güçlü bir ifadedir. Ve ekran size bir şeye daha karar verdirir: “ABC” ile “abc” aynı değer mi, farklı mı? Bir insanın yazdığı her şey için büyük/küçük harfe duyarsız olmak daha güvenli varsayılandır. 2. bölümün anahtar kuralı, benzersiz, değişmez, anlamsız, asla kişisel veri değil, burada da geçerlidir. Biri bana çalışan e-postasının benzersiz olduğunu söylerse sormaya başlarım: değişebilir mi, biri ayrılıp geri dönebilir mi, adresler yeniden kullanılabilir mi, bir satın almadan sonra ne olur? E-posta yararlı olabilir, bugün benzersiz bile olabilir. Bu onu iyi bir kimlik yapmaz.

Harici Kimlikler: Sınırın Ötesinde Kimlik

Harici Kimliklerin (External ID) hakkını verdiği yer burası. Ekran onu iyi tanımlar: alan “harici bir sistemden gelen benzersiz kayıt tanımlayıcısı” olur. ERP’de 873492 numaralı müşteri var; Salesforce’un kendi kayıt kimliği var. ERP bir güncelleme gönderdiğinde onun hangi kayda ait olduğunu nasıl biliriz? Bir alanı Harici Kimlik olarak işaretleyin, bir entegrasyon onun üzerinden upsert yapabilir: kayıt yoksa oluşturur, varsa günceller (Upsert a Record Using an External ID (opens in a new tab), İngilizce). Ve alt kayıtları yüklerken önce Salesforce kimliğini sorgulamak yerine üst kayda Harici Kimliği üzerinden işaret edebilirsiniz. Aramayı Salesforce’un sizin yerinize yapmasına izin verdiğinizi söylemeyi severim. Çok güçlü.

ERP’nin numarasının Salesforce kaydının kimliği olmadığına dikkat edin. Bir özniteliktir ve bir kayıt birkaç tane taşıyabilir: bir ERP müşteri kimliği, bir eski sistem kimliği, bir ortağın kimliği. Bu sorun değil. Tek bir iş varlığı birkaç sistem tarafından farklı biçimlerde bilinebilir. Mimari soru, her tanımlayıcının hangi sisteme ait olduğu ve hangi sözü verdiğidir: onu ancak iş bunu gerçekten garanti ediyorsa benzersiz olarak işaretleyin.

Tür Tür Alanlar

Şimdi türlerin kendisi. Herhangi bir nesnede Yeni Alan’ı (New Field) açın, Kurulum size tüm listeyi gösterir; benim üzerinden geçeceğim şekilde gruplanmıştır: Salesforce’un sizin için hesapladığı alanlar, ilişki alanları ve ardından veri türleri.

Kurulum, Yeni Özel Alan, 1. adım: veri türleri (ekran görüntüsü, 2026-10-12). Tam boyut

İşte tüm liste bir bakışta; her biri hakkında hatırlamanızı istediğim tek şeyle birlikte.

Grup	Tür	Hatırlayın
Hesaplanan	Otomatik Numara	En fazla 30 karakter, bunların 20’si önek ya da sonek; insanlar için bir etiket, kaydın kimliği değil
	Formül	Saklanmaz, okunduğunda hesaplanır; 3.900 karakter
	Toplama Özeti	Ayrıntı kayıtlarının sayısı, toplamı, en küçüğü ya da en büyüğü; yalnızca ana-ayrıntı
İlişkiler	Arama, Ana-Ayrıntı, Harici Arama	7. modül
Veri	Onay Kutusu	Seçtiğiniz bir varsayılanla doğru ya da yanlış; akışlarda null yine de görünebilir
	Sayı, Yüzde, Para Birimi	Yuvarlama kuralları; baştaki sıfırlar atılır; 15 ondalık basamak
	Tarih, Tarih/Saat, Saat	Bir gün, bir an ya da günün bir saati; anlar UTC olarak saklanır
	E-posta, Telefon, URL	Kaydederken biçimlendirilir ve denetlenir: 80, 40 ve 255 karakter
	Coğrafi Konum, Adres	Tek bir alandan fazlasına mal olan bileşik alanlar: 3 ve 9
	Seçim Listesi, Çoklu Seçim	Bir yöneticinin sahip olduğu kontrollü bir sözcük dağarcığı
	Metin, Metin Alanı, Uzun, Zengin, Şifreli	Kayıtta en fazla 255 ve dizinlenebilir; bunun üstünde dizin ya da filtreleme yok

Salesforce’un Hesapladığı Alanlar

Otomatik Numara (Auto Number), her yeni kayda bir dizideki sonraki numarayı, sizin tanımladığınız bir biçimde atar; örneğin T-{000000}. Bir insanın kullanışlı bir tutamağa ihtiyacı olduğunda ve kimsenin bir tane uydurmak zorunda kalmaması gerektiğinde kullanın. Değerin tamamı en fazla 30 karakterdir ve bunların 20’si önek ya da sonek için ayrılmıştır. Yalnızca 2. bölümden hatırlayın: insanlar için bir etikettir, kaydın kimliği değil; ve numaralar her zaman kesintisiz sıralı değildir.

Formül alanları bir değeri diğer alanlardan hesaplar. Güçlüdürler ve kayıt kaydedildiğinde değil, okunduğunda hesaplanırlar; dolayısıyla bayatlayacak saklı bir şey yoktur. Formülün ne döndüreceğini siz seçersiniz: onay kutusu, para birimi, tarih, tarih/saat, sayı, yüzde, metin ya da saat.

Yeni Özel Alan, formül: dönüş türünü seçmek (ekran görüntüsü, 2026-10-12). Tam boyut

Ardından formülün kendisini alanlar, operatörler ve fonksiyonlarla yazar ve söz dizimini denetlersiniz. Use Formula Assistant (Formül Asistanını Kullan) düğmesine dikkat edin: Salesforce’un yapay zekâsı artık formülü yazmanıza yardım edecek. Kullanın, sonra yazdığını okuyun. Formülün sahibi asistan değil, sizsiniz.

Formül Asistanıyla birlikte formül düzenleyicisi (ekran görüntüsü, 2026-10-12). Tam boyut Bir formül en fazla 3.900 karakter olabilir ve kaydedildiğinde ya da derlendiğinde 15.000 baytı aşamaz; uzun bir formül birbirine başvuran birkaç formül alanına bölünebilir. Uzun metin alanları, şifreli alanlar ve Açıklama alanları formüllerde kullanılamaz.

Toplama Özeti (Roll-Up Summary) alanları ana kayıtta durur ve onun ayrıntı kayıtlarını sayar, toplar ya da en küçüğünü veya en büyüğünü alır. Yalnızca bir ana-ayrıntı ilişkisi boyunca çalışırlar; bu da ana-ayrıntıyı seçmenin en büyük nedenlerinden biridir. Onlara ve sınırlarına 7. modülde döneceğiz.

Saklanan mı, Türetilen mi?

Bu değeri hiç saklamamız gerekiyor mu? Miktar ve birim fiyatım varsa birinin ya da bir otomasyonun bir toplamı güncel tutması mı gerekiyor? Belki bir formül onu türetmeli: hesaplama için tek bir kaynak, okunduğunda yeniden hesaplanır; miktarı değiştirin, yanıt da onu izlesin. Formüllerin kendi sınırları vardır (kaydetme boyutu ve görüntülenen uzunluk; Formula Field Limits and Restrictions (opens in a new tab), İngilizce) ve karmaşık olanların bakımı zorlaşır.

Ama bazen iş bugünün yanıtını istemez. Yanıtı olduğu haliyle ister. İndirim kuralı gelecek yıl değişirse geçen yılın faturası birden farklı bir tutar mı göstermeli? Elbette hayır. Dolayısıyla soru “Salesforce bunu hesaplayabilir mi?” değildir. “Bu güncel bir hesaplama mı, yoksa tarihsel bir olgu mu?” sorusudur. Tarihsel olgular saklanır.

İlişki Alanları

Arama (Lookup), Ana-Ayrıntı (Master-Detail) ve Harici Arama (External Lookup) ilişkileri de alandır ve modelinizdeki çizgiler onlarla gerçeğe dönüşür. Arama gevşek bağdır; ana-ayrıntı alt kaydın hayatını, sahipliğini ve güvenliğini üst kayda bağlar; harici arama 4. modüldeki bir harici nesneye, onun Harici Kimliği üzerinden eşleşerek ulaşır. Aralarında seçim yapmak kendi modülünü hak edecek kadar büyük bir karardır.

Onay Kutusu

Onay kutusu (checkbox) var olan en basit alandır: doğru ya da yanlış, işaretli ya da işaretsiz. Kayıt hakkında evet/hayır türünden bir olgu için mükemmeldir: Aktif mi, Kurulum Gerekli, İmzalı Teslim. Bir tane oluşturduğunuzda Salesforce sizden varsayılan değerini, işaretli ya da işaretsiz, seçmenizi ister ve bu gerçek bir karardır: her yeni kayıt bununla başlar, bir entegrasyonun alanı göndermeden oluşturduğu kayıtlar da dahil. Raporlar ve liste görünümleri onu True ve False olarak filtreler; içe aktarma araçları ve haftalık dışa aktarma onu 1 ve 0 olarak gösterir.

Bilinmesi gereken bir tuzak var. Kayıttaki alanın iki değeri vardır, ama etrafındaki otomasyonun üçüncü bir değeri olabilir. Bir akışta hiç atanmamış bir onay kutusu değişkeni false değil null’dır ve onu bir kayda kaydetmek başarısız olur (Trailblazer Community (opens in a new tab); ayrıca Salesforce bilinen sorunu W-11208535 (opens in a new tab)). Mantıklı bir varsayılan seçin ve akışlarınızın ve kodunuzun null’ı bilinçli olarak ele almasını sağlayın.

Sayı, Yüzde ve Para Birimi

Sayı (Number) gerçek bir sayı saklar ve baştaki sıfırları atar; 001247 gibi bir filo numarasının Sayı olmamasının nedeni de tam olarak budur. Salesforce sayı alanlarını sıfırdan uzağa doğru yarım yuvarlar: 12,345, 12,35 olur ve −12,345, −12,35 olur. Ve birleştirme alanlarında (merge fields) alanda belirlediğiniz ondalık basamaklara göre değil, kullanıcının yerel ayarına göre yuvarlar.

Yüzde (Percent) bir ondalık sayı saklar ve bir yüzde gösterir: 0,10 girersiniz, %10 görürsünüz. Değerler 15 ondalık basamaktan sonra hassasiyet kaybeder.

Para Birimi (Currency) para için biçimlendirilir ve birden fazla para birimi olan bir org’da kendi para birimi kodunu taşır ve döviz kurlarını kullanabilir; gelişmiş para birimi yönetimiyle (opens in a new tab) (İngilizce) fırsatlar tarihli döviz kurlarını, yani anlaşmanın kapandığı dönemin kurunu kullanabilir. Tarihli kurları yalnızca fırsatlar ve çevresindekiler (ürünler, takvimler, bölüşümler ve bunların raporları) kullanır; diğer nesnelerdeki para birimi alanları tek, sabit kuru korur. Yuvarlamaya dikkat edin: ondalık basamak yoksa Salesforce basitçe keser (23,5, 23 olur); bir veya daha fazla basamak varsa sıfırdan uzağa doğru yarım yuvarlar.

Tarih, Tarih/Saat ve Saat

Üç tür, üç farklı anlam. Tarih (Date) bir gündür: bir sözleşme bir tarihte sona erer. Tarih/Saat (Date/Time) bir andır: teslimat o sabah 9.42’de ulaştı. Saat (Time) hiç tarihi olmayan, günün bir saatidir: mağaza her gün 7.00’de açılır.

Tuzak andadır. Salesforce tarih/saat değerlerini GMT (UTC) olarak saklar. Kullanıcının yazdığı saat onun saat diliminde okunur, dönüştürülür ve saklanır; biri onu okuduğunda yeniden okuyanın saat dilimine dönüştürülür. Çoğu zaman tam istediğiniz budur. Ama derste verdiğim örnek şu: Los Angeles’taki bir koordinatör pazar gecesi geç saatte, Pasifik saatiyle 22.00’de bir teslimatı kaydediyor. Arka planda Salesforce pazartesi sabahı, GMT 05.00’i sakladı. Başka bir saat diliminde güne göre gruplanmış bir rapor ya da ham değeri okuyan bir entegrasyon, o pazar teslimatını pazartesiye koyabilir. “Olduğu gün” kimin saatine sorduğunuza bağlıdır. Kullanıcıların saat dilimlerini izleyin ve işin hangisini kastettiğine karar verin.

Ve onları karşılaştırırken dikkatli olun. Arka planda bir tarih/saat tek bir büyük sayıdır: Apex onu 1 Ocak 1970, 00:00:00 GMT’den bu yana geçen milisaniye sayısı olarak okur (Datetime Class (opens in a new tab), İngilizce). Kesin bir andır, bir gün değil. Bu yüzden iki tarih/saatin eşit (==) olup olmadığını sormak neredeyse hiçbir zaman istediğinizi yapmaz: 9.42.00 ile 9.42.01 eşit değildir, “pazartesi” ile pazartesi günündeki herhangi bir an da eşit değildir. Bunun yerine bir aralık isteyin: başlangıçta veya sonrasında (>=) ve bitişte veya öncesinde (<=). “Pazartesi günkü her teslimat”, işin kastettiğine karar verdiğiniz saat diliminde pazartesi 00.00’a >= ve pazartesi 23.59.59’a <= olan her teslimattır.

Bir de eğlenceli olanı: Salesforce her tarihi saklayamaz. Geçerli tarihler 1 Ocak 1700’den 31 Aralık 4000’e kadar uzanır ve Salesforce tarihler ve tarih/saatler için aynı aralığı verir (Data Import Dates (opens in a new tab), İngilizce). Uç noktalar bile GMT’deki anlardır; dolayısıyla Pasifik saatindeki bir kullanıcı için geçerli en erken değer 31 Aralık 1699 saat 16.00’dır. Tarih derneğinizin kuruluş tarihi sığmayabilir. Ve klasik “bitiş tarihi yok” hilesi, 31 Aralık 9999, reddedilir; uzak gelecekte bir yer tutucuya ihtiyacınız varsa 4000 yılında ya da öncesinde olmalıdır.

E-posta, Telefon ve URL

Bunlar biçimlendirilmiş alanlardır ve karakter saklamaktan fazlasını yaparlar. E-posta (Email) en fazla 80 karakter tutar ve düzgün bir biçim için denetlenir; kişilerde ve potansiyel müşterilerde ona tıklamak o adrese bir e-posta başlatır. Telefon (Phone) en fazla 40 karakter tutar, telefon numarası olarak biçimlendirilir ve org’a bir telefon sistemi bağlıysa tıkla-ara özelliğine dönüşür. URL en fazla 255 karakter tutar ve bağlantı olarak açılır. Bu, platformun size bedavaya davranış vermesidir; bu yüzden bir telefon numarasını asla düz bir metin alanında saklamam.

Entegrasyonlar da denetlenir. Alanın biçimine uymayan bir değer, örneğin hatalı biçimlendirilmiş bir e-posta adresi, doğrulamada başarısız olur ve yalnızca o alan değil, tüm kayıt reddedilir. Bu yüzden kaynak sistemin verisi dağınıksa, gelmeden önce temizleyin ya da yüklenmeyecek kayıtlar için plan yapın.

Coğrafi Konum ve Adres

Coğrafi Konum (Geolocation) bir enlem ve bir boylam tutar. Arka planda Location__c adlı bir alan aslında ayrı ayrı okuyup atayabileceğiniz iki değerdir: Location__Latitude__s ve Location__Longitude__s. Ve onun üzerinde sorgu yapabilirsiniz: SOQL’in DISTANCE ve GEOLOCATION fonksiyonları bir yarıçap içindeki kayıtları bulur ya da onları ne kadar uzakta olduklarına göre sıralar. “Bu kamyonun 25 mil yakınındaki her açık teslimat” tek bir sorgudur: WHERE DISTANCE(Location__c, GEOLOCATION(33.45, -112.07), 'mi') < 25 (Location-Based SOQL Queries (opens in a new tab), İngilizce). Adres (Address) bütün bir adresi tutar: sokak, şehir, eyalet ya da il, posta kodu ve ülke; kullanıcılar bir adres arayıp parçaların doldurulmasını sağlayabilir.

İkisi de bileşik alanlardır: ekranda tek alan, arka planda birkaç alan. Ve nesnenizin sınırına karşı tek bir alandan fazlasına mal olurlar: bir Coğrafi Konum üç özel alan, bir Adres dokuz özel alan sayılır. Zaten kalabalık bir nesnede bu önemlidir.

Seçim Listesi ve Çoklu Seçim

Bir seçim listesi kullanıcıların ne girebileceğini kontrol eder: sizin tanımladığınız bir listeden tek bir değer. Durum mu? Muhtemelen seçim listesi. Ama değerler meta veridir ve onları bir yöneticinin eklemesi ya da değiştirmesi gerekir. Bu yüzden yine de sorarım: değerlerin sahibi kim, ne sıklıkla değişiyorlar, birkaç nesnenin aynı listeye ihtiyacı var mı, değerler kendilerine ait bilgi taşıyor mu ve sözcük dağarcığının sahibi başka bir sistem mi?

Değerlerin nerede yaşadığı da bir karardır. Bir liste tek bir alanda bir kez kullanılıyorsa değerleri alanın kendisinde, nesnede tutun; Salesforce varsayılan olarak bunu yapar. Ama aynı değer kümesi birkaç yerde görünmeye başladığında, hesapta, teslimatta ve depoda bir Bölge gibi, kopyalar birbirinden uzaklaşmadan önce onu bir genel değer kümesine yükseltin. Bir genel değer kümesi hepsi için tek bir liste tutar; aktif ve pasif toplam en fazla 1.000 değer (Picklist Limitations (opens in a new tab), İngilizce). Kurulum’un kendi açıklaması neden önemli olduğunu söyler: değer kümesi “kullanıcıların API üzerinden onaylanmamış değerler ekleyemeyeceği şekilde kısıtlanmıştır.” Tek liste, tek sahip ve yeni bir yazımı içeri sızdıran entegrasyon yok.

O son nokta kısıtlı ile kısıtsız arasındaki farktır. Kısıtlı bir seçim listesinde yalnızca bir yöneticinin tanımladığı değerlere, nereden gelirse gelsin, izin verilir: başka bir şey gönderen bir kullanıcı, içe aktarma ya da entegrasyon bir hata alır, “bad value for restricted picklist field”, ve kayıt kaydedilmez. Kısıtsız bir seçim listesinde kullanıcılar ekranda yine listeden seçer, ama API, içe aktarmalar ve otomasyon herhangi bir değer gönderebilir; Salesforce onu kaydeder ve pasif bir değer olarak ekler (Picklist Limitations (opens in a new tab); Create a Custom Picklist Field (opens in a new tab), İngilizce). Bir org’un sonunda “Delivered”, “delivered” ve “Dlvrd” ile kalması böyle olur. Genel değer kümeleri her zaman kısıtlıdır. Benim varsayılanım kısıtlıdır; kısıtsız, değerlerin sahibi gerçekten başka bir sistem olduğunda bilinçli bir seçimdir ve o zaman pasif değerleri temizlemekten de biri sorumludur.

Kurulum, Seçim Listesi Değer Kümeleri: yeni bir genel değer kümesi (ekran görüntüsü, 2026-10-12). Tam boyut

Çoklu seçim listesi, kullanıcının birkaç değer seçmesine izin verir; değerler noktalı virgülle ayrılarak birlikte saklanır. Ekranda kullanışlı, başka her yerde zahmetli: filtrelemesi, raporlaması ve entegre etmesi daha zordur ve bir toplama özetinin filtresinde kullanılamaz. Bir kayıt için birkaç değer genellikle 2. bölümün dersi anlamına gelir: dışarı çıkmaya çalışan bir alt nesne var.

Bir seçim listesinin tanımladıklarınızdan bir değeri daha vardır: boş. Bir kayıt hiçbir şey seçilmeden durabilir ve bu insanları yakalar. Bir formülde ya da doğrulama kuralında bir seçim listesini tek başına ISBLANK ile test edemezsiniz; ISBLANK(TEXT(Field__c)) ya da ISPICKVAL(Field__c, "") yazarsınız (Trailblazer Community (opens in a new tab)). Bu yüzden her seçim listesi için “değer yok”un ne anlama geldiğine karar verin: izin veriliyor mu ve olduğunda ne anlama geliyor? Sonra formüllerinizin, doğrulama kurallarınızın ve filtrelerinizin bunu ele almasını sağlayın.

Ve bazen bir öznitelik aslında bir varlıktır. Biri dağıtım merkezleri için bir seçim listesi ister. Dokuz tane var. Kolay. Sonra her birinin bir adresi, bir müdürü, çalışma saatleri, kapasitesi, bir bölgesi ve kamyonları olduğunu öğreniriz. Bu bir seçim listesi değil; bu bir şey. Henüz çok fazla yok diye bir varlığı seçim listesine dönüştürmeyin. Birinci yılda harika, beşinci yılda berbat hissettirir. (2. bölümün 5. modülünde bir listenin ne zaman kendi nesnesini hak ettiğine dair pratik kurallarım var.)

Metin Ailesi

Metni iki tür olarak öğretirim ve aralarındaki çizgi 255 karakterdir.

255’e kadar: kayıtla birlikte saklanır. Metin (Text) en fazla 255 karakter tutar ve onu neredeyse her yerde kullanabilirsiniz: formüllerde, filtrelerde, raporlarda, liste görünümlerinde, benzersiz alan ya da Harici Kimlik olarak; ve dizinlenebilir. Metin Alanı (Text Area) da 255 tutar, ayrı satırlarda, kısa bir not gibi.

255’in üstü: başvuruyla saklanır. Metin Alanı (Uzun) (Text Area (Long)) en fazla 131.072 karakter tutar, Metin Alanı (Zengin) (Text Area (Rich)) da aynısını biçimlendirme, bağlantılar ve görsellerle tutar. Onları kenarda saklanıyor, kaydın da bir işaretçi tutuyor olarak düşünürüm ve öyle davranırlar: dizin yok, dolayısıyla onları benzersiz ya da Harici Kimlik yapamazsınız; bir SOQL WHERE yan tümcesinde onlara göre filtreleyemezsiniz (SOQL WHERE (opens in a new tab), İngilizce); formüller onları kullanamaz (Formula Field Limits and Restrictions (opens in a new tab)); raporlar özel olanların yalnızca ilk 254 karakterini gösterir, rapor filtreleri de yalnızca yaklaşık ilk 255 karakterde arar (Filter Restrictions for Text Area (Long) Fields (opens in a new tab)). Zengin metin alanına yüklenen görsellerin her biri en fazla 1 MB olabilir ve dosya depolamasından düşülür, metin ise veri depolamasından düşülür (Rich Text Area Field Considerations (opens in a new tab)). Dolayısıyla biri değer üzerinde arama, sıralama, eşleştirme ya da raporlama yapacaksa onu 255’in altında ve bir Metin alanı olarak tutun.

Metin (Şifreli) (Text (Encrypted)), Klasik Şifreleme (Classic Encryption) kullanarak en fazla 175 karakteri şifreli biçimde saklar. Org’unuz Shield Platform Encryption kullanıyorsa bunun yerine sıradan bir Metin alanını şifrelersiniz ve diğer birçok tür de bu şekilde şifrelenebilir.

Her Alana Bir Açıklama Verin

Standardım: her alan bir açıklama alır. Buna uzun zamandır inanıyorum ve yapay zekâ çağında her zamankinden daha önemli: org’unuzu okuyan her yapay zekâ aracı ve ajan, bir alanın ne anlama geldiğini anlamak için açıklamaları okur. Boş bir açıklama, gerçekleşmeyi bekleyen bir tahmindir. Customer_Status__c ne anlama geliyor? Sahibi kim? Nereden geliyor? Kullanıcılar onu düzenleyebilir mi, yoksa ERP bu gece üzerine mi yazacak? Altı ay sonra hatırlamayacağım ve üç yıl sonra org’un bakımını yapan yönetici, biz söylemediysek bilmeyecek. Etiket belgeleme değildir, API adı da değildir.

Yoğun biçimde paylaşılan nesnelerde (Hesap, Kişi, Fırsat) özel amaçlı alanlar için adlandırma önekleri de kullanırım; böylece kökenleri ve amaçları adın kendisinde görünür: örneğin ERP’nin sahip olduğu her şey aynı önekle başlar. On iki sözcüklük API adları peşinde değilim. Modelin kendini açıklamasını istiyorum.

Önemli Olanı Sınıflandırın: Taksonomi Alanları

Salesforce her alana bir dizi sınıflandırma meta verisi verir. Ben bunlara taksonomi alanları derim. Veri sahibini; alan kullanımını (Active, DeprecateCandidate, Hidden); veri hassasiyet düzeyini (Public, Internal, Confidential, Restricted, MissionCritical); ve uyumluluk sınıflandırmasını kaydedebilirsiniz: PII, HIPAA, GDPR, PCI, CCPA ve diğerleri. Özel alanlarda olduğu kadar standart alanlarda da çalışırlar (Data Classification Metadata Fields (opens in a new tab), İngilizce).

Neden uğraşmalı? Çünkü süreçler onları okuyabilir. Bir alanı GDPR olarak işaretleyin, bir süreç bir kayıttaki her GDPR alanını bulup maskeleyebilir ya da kaldırabilir. Ve Salesforce’un güven katmanı büyük bir dil modeline bir istem gönderdiğinde hassas alanları maskelemek için tam olarak bu sınıflandırmayı kullanabilir: giderken bir müşterinin adını, diyelim “Maria Lopez”i, bir yer tutucuyla değiştirir, model adı hiç görmez ve dönüşte ad yanıta geri yerleştirilir (Einstein Trust Layer (opens in a new tab), İngilizce).

Bir güncelleme. Salesforce artık büyük dil modelleri için kalıp tabanlı ve alan tabanlı maskelemenin ajanlar için devre dışı olduğunu belgeliyor: maskeleme, bir ajanın yanıt vermek için ihtiyaç duyduğu bağlamı silebilir (Data Masking Limitations in Agentforce (opens in a new tab), İngilizce). Sınıflandırma diğer üretken yapay zekâ özellikleri için maskelemeyi hâlâ yönlendirir, ama kişisel veriyi bir ajandan uzak tutmak için ona güvenmeyin; bu bir erişim ve tasarım kararıdır (12. bölüm).

Pozisyonum: sınıflandırma kilit anlarda önemlidir. Yönetişim öyle dedi diye onu her kutuyu doldurmakla geçen üç haftaya dönüştürmeyin. Önemli olduğu yerde kullanın: kişisel veri, finansal veri, düzenlemeye tabi veri ve işin adı konmuş bir sahibe ihtiyaç duyduğu alanlar. Amaç, hassasiyetin birinin kafasındaki bilgi olmaktan çıkıp alanın bir parçası haline gelmesidir.

Sınavın ötesinde: yapay zekânın değiştirdikleri. Zayıf alan belgelemesi eskiden bir sonraki yöneticiyi cezalandırırdı. Şimdi şemayı okuyan her yapay zekâ aracını ve ajanı yanıltıyor: Flag2__c hassas mı, esas mı, hâlâ kullanılıyor mu? Yapay zekâ ayrıca alanları herhangi bir ekipten daha hızlı oluşturuyor; dolayısıyla adlar, açıklamalar ve sınıflandırma ev işi değil, mimarinin bir parçasıdır.

Her Alan Bir Taahhüttür

Bir alan bir kez dışarıda veri toplamaya başladığında her şey ona yaslanmaya başlar. Ekranlar onu gösterir, akışlar ona göre dallanır, doğrulama kuralları onu denetler, raporlar ona göre gruplar, entegrasyonlar onu gönderir ve okur, ve artık yapay zekâ araçları onun üzerinden akıl yürütür. Her biri alan hakkında varsayımlarda bulunur: türü, uzunluğu, hiç boş olup olmadığı ve değerlerinin ne anlama geldiği. Alanı sonradan değiştirirseniz önce o varsayımların her birini bulmanız gerekir. Bir seçim listesi değerini yeniden adlandırmak, bir metin alanını kısaltmak ya da bir Metin alanını seçim listesine dönüştürmek küçük bir değişiklik gibi görünür ve başka bir şirketin sistemindeki bir entegrasyonu bozabilir. Bir alanın bir taahhüt olmasının nedeni budur.

Click to enlarge

Bu modülden alan oluşturmaktan korkarak ayrılmanızı istemiyorum. Salesforce genişletilmek için inşa edildi; bunu kullanın. Sorunun “hangi alan türünü seçmeliyim?”den **“bu veri ne anlama geliyor ve hangi davranışı taahhüt ediyoruz?”**a dönüşmesini istiyorum. Tür, zorunlu, benzersiz, Harici Kimlik, seçim listesi, formül, açıklama, sınıflandırma: birlikte, 2. bölümün mantıksal modelinin fiziksel ifadesidirler.

Mimarın Burada Karar Verdikleri

• Alan türünü seçmeden önce değerin ne anlama geldiği ve bir öznitelik mi, bir tanımlayıcı mı, kontrollü bir sözcük dağarcığı mı yoksa aslında başka bir varlık mı olduğu.
• Bir değerin türetilebilecek güncel bir hesaplama mı, yoksa saklanması gereken tarihsel bir olgu mu olduğu.
• Her tanımlayıcının hangi sisteme ait olduğu ve benzersizliğinin gerçek bir iş sözü olup olmadığı.
• Zorunlu bir değerin gerçekte ne zaman bilindiği ve ona sahip olmayan kayıtlara ve entegrasyonlara ne olacağı.
• İnsanların, süreçlerin ve yapay zekânın onu güvenle kullanabilmesi için alanın hangi açıklamaya, adlandırmaya ve sınıflandırmaya ihtiyaç duyduğu.

Daha Fazlası

• Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-02.
• Salesforce Help, Einstein Trust Layer: Designed for Trust (opens in a new tab) ve Data Masking Limitations in Agentforce (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-02.
• Salesforce Developers, Insert or Update (Upsert) a Record Using an External ID (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-02.
• Salesforce Help, Picklist Limitations (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-02.
• Salesforce Help, Formula Field Limits and Restrictions (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-02.
• Salesforce Developers, Date Formats and Date Literals (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-02.