Salesforce Veri Mimarisi

🌐 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ünün çalışma rehberi. Önce on modülü okuyun; bu sayfa aklınızda neyin kaldığını kontrol etmenize yardım eder.

Bu çalışma rehberi hakkında. Yalnızca bu kursun kendi içeriğinden ve Salesforce’un yayımladığı sınav rehberindeki hedefler listesinden hazırlanmıştır. Hiçbir zaman gerçek sınav sorularına dayanmaz ve sınavda ne olduğunu bildiğini iddia etmez. Sınava girdiyseniz lütfen bana sınavdan soru göndermeyin: sertifika sözleşmesi bunları paylaşmayı yasaklar ve zaten yanıt ezberlemek mimar olmanın yanlış yoludur.

Bu, modelin platformla buluştuğu bölümdür ve sınavın büyük bir kısmını taşır. Her biri sınavın dörtte biri olan en büyük iki kısmı, Veri Modelleme ve Veritabanı Tasarımı ile Salesforce Veri Yönetimi’ni besler. Platform sayıları değişir: kontrol listesi, modüllerin alıntıladığı sayıları kontrol edildikleri tarihle birlikte verir. Her sınırın ne işe yaradığını öğrenin ve ona güvenmeden önce güncel sayıyı kontrol edin.

Sınav İçin

İlerledikçe işaretleyin. Her madde öğretildiği yere bağlanır.

DM-1: veri modelini platformda tasarlamak

• Salesforce’un meta veri odaklı, çok kiracılı bir platform olduğunu bilirim: bir nesne yeni bir tablo değil, meta veridir ve her nesne var olduğu anda API’lerini alır. (Meta Veri Plandır, API’niz Nesneyle Birlikte Geldi)
• Yönetici sınırlarının (governor limits) bir kiracının paylaşılan kaynakları ele geçirmemesi için var olduğunu bilirim. (Asansörü Ele Geçiremezsiniz)
• Standart veri modellerini okuyabilirim: Potansiyel Müşterinin Hesap, Kişi ve Fırsat’a dönüştürülmesi; bir Fırsat Ürününün bir Price Book Entry’ye (fiyat listesi girişi), onun da Product2’ye işaret etmesi; servis tarafında da Vaka, Varlık ve Yetkilendirme (Entitlement). (Satış Modeli, Hizmet Modeli)
• Yeni Özel Nesne (New Custom Object) ekranının neye karar verdiğini bilirim: Metin ya da Otomatik Numara kayıt adı; Nesne Sınıflandırması (paylaşım, Bulk API ve Streaming API açıkken Enterprise Application nesnesi, kapalıyken Light Application nesnesi); ve varsayılan olarak kapalı olan Allow Search (Aramaya İzin Ver). (Yeni Özel Nesne Ekranı)
• Bir API adını okuyabilirim: standart nesnelerin ve alanların öneki ya da soneki yoktur; özel nesneler ve alanlar __c ile biter; yönetilen bir paket kendi ad alanı önekini (abc__) ekler; ve bir paketin nesnesine sizin eklediğiniz bir alan __c alır ama asla satıcının önekini almaz. (Önekler ve Sonekler)
• Bir standart nesne için tam uyum testini uygulayabilirim ve anlamın ya da ağırlığın ne zaman özel bir nesneye işaret ettiğini bilirim. (Tam Uyum Testi)
• Varlık’ın ve kişi hesaplarının ne işe yaradığını, bir kişi hesabının bir işletme hesabının yaklaşık iki katı depolama alanı kapladığını ve kişi hesapları bir kez etkinleştirildiğinde devre dışı bırakılamayacağını bilirim. (Varlık İyi Bir Örnektir, Kişi Hesapları, Kişi Ne Zaman Hesaptır?)
• Alan türünü ihtiyaç duyduğum davranışa göre seçerim (bir filo numarası Sayı değildir) ve tarih/saatin GMT olarak saklanıp her okuyucunun saat diliminde gösterildiğini, bu yüzden eşitlikle değil aralıklarla karşılaştırıldığını bilirim. (Bir Sayı Her Zaman Bir Sayı Değildir, Tarih, Tarih/Saat ve Saat)
• Metnin iki türde geldiğini bilirim: kayıtta en fazla 255 karakter (dizinlenebilir, benzersiz ya da Harici Kimlik olarak kullanılabilir) ve bunun üstünde dizini, WHERE filtrelemesi ve formül kullanımı olmayan Uzun ya da Zengin metin. (Metin Ailesi)
• Otomatik numaralı bir Ad alanını ne zaman kullanacağımı ve bunun kaydın kimliği olmadığını bilirim. (Bir İnsanın Onu Tanımlaması Gerekiyor mu?)
• Bir Harici Kimliğin, bir entegrasyonun upsert yapmasını ve alt kayıtları üst kaydın Harici Kimliği üzerinden yüklemesini nasıl sağladığını bilirim. (Harici Kimlikler)
• Bir değerin ne zaman bir formülle türetilmesi gerektiğini ve ne zaman saklanması gereken tarihsel bir olgu olduğunu bilirim. (Saklanan mı, Türetilen mi?)
• Bir mantıksal bağlantı nesnesi (modelleme fikri: iki nesneyi çoka-çok bir ilişkide birleştiren, kendi öznitelikleri olan bir nesne) ile bir Salesforce bağlantı nesnesi (Salesforce Junction Object; iki ana-ayrıntı ilişkisi olan bir özel nesne) arasındaki farkı ve Salesforce’un ikincisini kastettiğini bilirim. (İki Üst Kayıt Genişlik)
• Hiyerarşik ilişkiyi bilirim: yalnızca Kullanıcı nesnesinde olan, standart Manager alanı gibi, doğrudan ya da dolaylı olarak aynı kullanıcıya geri dönemeyen ve rol hiyerarşisi olmayan özel bir arama ilişkisi. (Hiyerarşik)
• Arama ilişkisi ile ana-ayrıntı arasındaki farkı bilirim: sahiplik, paylaşım, zorunlu üst kayıt, zincirleme silme, toplama özetleri. (Arama İlişkisi, Ana-Ayrıntı)
• Ana-ayrıntının zaten verisi olan bir nesnede oluşturulamayacağını (bir arama ilişkisi oluşturun, doldurun, dönüştürün), ancak ana kayıtta toplama özeti yokken arama ilişkisine geri dönebileceğini ve bir alt kaydı taşımak için Allow reparenting (Yeniden üst kayda bağlamaya izin ver) gerektiğini bilirim. (Alt Kayıt Üst Kaydını Değiştirebilir mi?)
• Platformun ana-ayrıntı için şeklini bilirim: en fazla üç özel ayrıntı düzeyi derin (bir arama ilişkisi zinciri herhangi bir yerde kırabilir) ve iki ana-ayrıntı üst kaydı geniş. Bir Salesforce bağlantı nesnesinde ilk oluşturulan ana-ayrıntı birincildir (sahip, görünüm, bölüm), ikincisi ikincildir ve erişim iki üst kaydı da gerektirir: en kısıtlayıcı olan kazanır. (Üç Düzey Derinlik, İki Üst Kayıt Genişlik)
• Üst kayıt silindiğinde bir arama ilişkisinin üç seçeneğini bilirim: alanı temizlemek (varsayılan), silmeyi engellemek ya da Salesforce etkinleştirene kadar kapalı olan ve paylaşımı atlayan zincirleme silme. (Arama İlişkisi)
• Bir kendine ilişkinin arama ilişkisi olması gerektiğini ve yerleşik iki tanesini bilirim: Hesap’ın Üst Hesap’ı ve Vaka’nın Üst Vaka’sı. (Kendine İlişkiler)
• Toplama özetinin yeniden hesaplanmasının zaman alabileceğini, bir toplama özetinin NOW(), TODAY() ya da nesneler arası başvuru içeren bir formülü kullanamayacağını ve yalnızca bir toplama özeti elde etmek için ana-ayrıntı seçilmemesi gerektiğini bilirim: alternatif, bir akış ya da tetikleyiciyle güncel tutulan saklı bir alandır. (Toplama Özetleri Yararlıdır ama Bedava Değildir)
• Modülün alıntıladığı ilişki sınırlarını bilirim: nesne başına iki ana-ayrıntı; varsayılan olarak 40 ilişki alanı (en fazla 50); varsayılan olarak 25 toplama özeti (en fazla 40). (İlişkilerin de Sınırları Vardır)

DM-2: paylaşıma saygı gösteren ve ölçeklenen bir model

• Bir ana-ayrıntı alt kaydının kendine ait sahibi ve paylaşım tablosu olmadığını bilirim: erişim ana kaydı izler. (Sahiplik de Beraberinde Gelir)
• Üst-alt çarpıklığını bilirim: Salesforce’un önerisi tek bir üst kayıtta yaklaşık 10.000 alt kaydı aşmamaktır. (10.000 Alt Kayıt Sorusu)
• Sahiplik çarpıklığını (bir kullanıcının bir nesnenin 10.000’den fazla kaydına sahip olması) ve öneriyi bilirim: sahipliği yayın ya da o kullanıcıyı rol hiyerarşisinin dışında veya en üstte tek başına tutun ve paylaşım kurallarının kullandığı genel grupların dışında bırakın. (Sahiplik Bir Ölçek Sorununa Dönüşebilir)
• Paylaşım tablosunu bilirim: bir özel nesnenin paylaşım nesnesi Object__Share’dir; bir ayrıntı nesnesinin hiç yoktur, erişimi ana kayıttan gelir; ve bir sahip değişikliği manuel paylaşımları kaldırır, ama kendi nedeni olan Apex paylaşımını korur. (Paylaşım Tablosu)
• Entegrasyonların ve ajanların oluşturduğu kayıtların sahibinin kim olacağına, sahipliğin paylaşımı belirleyip belirlemediğine göre karar verebilirim. (Sistemlerin Oluşturduğu Kayıtların Sahibi Kim?)

DM-4: standart ve özel nesnelere karşı büyük nesneler

• Veri için üç yuvayı bilirim: çekirdekte (her gün üzerinde çalışılan sObject’ler), başvurulan (gerçeğin kaynağı başka bir sistemdir: Salesforce Connect’in harici nesneleri, __x, ya da özel çağrılar) ve arşivlenen (çekirdekte büyük nesnelerde, __b, ya da çekirdek dışında bir veri ambarında). (Çekirdekte ve Çekirdek Dışında)
• Harici nesnelerin her dokunulduklarında bir dış çağrı yaptığını, dolayısıyla gecikmenin ve kaynak sistemin erişilebilirliğinin önemli olduğunu bilirim. (Başvurulan)
• Büyük nesneleri bilirim: çok büyük hacimler, dizinleri üzerinden tam eşleşmeyle ya da aralıkla sorgulanır, standart arayüz ya da raporlama yok, yalnızca nesne ve alan izinleri, otomasyon yok. (Arşivlenen)
• Kayıtların çoğunun alan sayısından bağımsız olarak yaklaşık 2 KB veri depolama alanı sayıldığını ve dosyaların dosya depolamasında ayrı ölçüldüğünü bilirim. (İki Sütun ya da İki Yüz, Dosyalar ve Ekler)

SDM-1: lisanslar ve insanların kullanabileceği nesneler

• Üç dahili lisansı, Sales Cloud, Service Cloud ve Platform’u ve her birinin neyi kullanabildiğini bilirim. (Üç Dahili Lisans)
• Lisansların veri modelinin bir parçası olduğunu bilirim: Salesforce Platform kullanıcıları Potansiyel Müşterileri, Kampanyaları, Fırsatları ya da Tahminleri almaz ve Customer Community kullanıcıları Fırsat’ı kullanamaz. (Şimdi Her Şeyi Karmaşıklaştırayım: Lisanslar)
• Harici lisans katmanlarını bilirim: Customer Community, Customer Community Plus (raporlar, gösterge panoları, standart paylaşım), Partner Community (satış nesneleri); ve Partner Community’nin kişi hesaplarıyla kullanılamayacağını. (Stadyum)
• Üye tabanlı ile oturum tabanlı lisanslamayı ve her birinin hangi kitleye uyduğunu bilirim. (Nasıl Ödedikleri Tasarımı Değiştirir)
• Bazı platform lisanslarının kullanıcıları en fazla on özel nesneli tek bir uygulamayla sınırladığını ve bu sınır içinde çalışmak için kayıt türü kalıbını bilirim. (Lisans Modeli Şekillendirdiğinde)
• Salesforce Integration lisansının sistemden sisteme, yalnızca API kullanıcıları için olduğunu bilirim. (Artık Tek Kullanıcılar İnsanlar Değil)
• SLA raporlamasının Service lisansları gerektiren yetkilendirmelere ve kilometre taşlarına ihtiyaç duyduğunu bilirim. (Şimdi Her Şeyi Karmaşıklaştırayım: Lisanslar)

SDM-2: veriyi tutarlı tutmak

• Bir kuralı tutarlılık merdiveninin doğru basamağına yerleştirebilirim: alan türü ve sözcük dağarcığı, zorunlu ve benzersiz, doğrulama kuralları, yinelenen kayıt kuralları, otomasyon. (Veriyi Tutarlı Tutmak)
• Kısıtlı bir seçim listesinin listede olmayan değerleri API üzerinden bile reddettiğini ve bir genel değer kümesinin tek bir listeyi alanlar arasında paylaştırdığını (en fazla 1.000 değer) bilirim. (Birinci Basamak)
• Bir sayfa düzeni zorunluluğunun veriyi değil, yalnızca o ekranı koruduğunu ve doğrulama kurallarının her kaydetmede çalıştığını bilirim. (Arayüz Doğrulaması Veri Doğrulaması Değildir, Üçüncü Basamak)
• Bir doğrulama kuralının kapsamını ISNEW() ve ISCHANGED(), bir özel izin ya da bir canlıya geçiş tarihiyle sınırlayabilirim; her seçeneğin hangi kaydetmeleri (toplu bir sahip değişikliği ya da bir toplama özeti gibi benim kontrol etmediklerim dahil) hâlâ denetlediğini bilerek. (Eski Kayıt Sorunu)
• Eşleştirme kurallarını ve yinelenen kayıt kurallarını, modülün alıntıladığı sınırları (nesne başına beş etkin yinelenen kayıt kuralı, her birinde üç eşleştirme kuralı) ve bunların sistemler arası kimliği çözmediğini bilirim. (Dördüncü Basamak: Yinelenen Kayıt Kuralları)
• Yinelenen kayıt kurallarının aynı anda kaydedilen kayıtları karşılaştırmadığını, API ve içe aktarma kaydetmelerinin uyarısız engellendiğini ve bir kaydetme ile tetiklediği her şeyin tek bir işlem olarak geri alındığını bilirim. (Dördüncü Basamak, Ya Hep Ya Hiç)
• Workflow Rules ve Process Builder’ın desteğinin sona erdiğini bilirim; otomasyon Flow ya da Apex demektir. (Beşinci Basamak: Otomasyon)

Sınavın Ötesinde

Sınav taban, tavan değil. Bunlar bu bölümden, bir soru onları hiç sorsun ya da sormasın, bir mimarın ihtiyaç duyduğu alışkanlıklardır.

• Platformun bir şekli vardır. Genel amaçlı bir veritabanı için değil, üzerinde olduğunuz platform için tasarlayın.
• Ana gemiye bakın. Bir kavramı icat etmeden önce Salesforce’un onu nasıl modellediğine bakın.
• Her nesne bir taahhüttür: depolama, sınırlar, bir paylaşım modeli, lisanslar ve bağımlılıklar.
• Bir nesne seçmeden önce verinin nerede yaşadığını sorun: çekirdekte, başvurulan ya da arşivlenen.
• Herhangi bir API adını okuyun, onu kimin yaptığını bilirsiniz, neyi değiştirebileceğinizi de.
• Bugün arşivlemiyorsanız, hiç arşivleyecek misiniz?
• Büyük nesneleri önermeden önce prototipini yapın.
• Farklı iş adları otomatik olarak farklı nesneler anlamına gelmez.
• Veriye hangi kimliklerin ihtiyaç duyduğunu sorun: insanlar, müşteriler, ortaklar, entegrasyonlar ve ajanlar.
• Her alan bir açıklama alır, önemli olduğu yerde de sınıflandırma.
• Önce ilişkinin davranışını tanımlayın; yapılandırma onu uygular. Bir özellik elde etmek için modeli çarpıtmayın.
• Silme sorusu: biri üst kaydı silerse alt kayıtlara ne olmalı?
• Zinciri hangi bağlantının kıracağını seçin: arama ilişkisini, alt kaydın gerçekten kendi hayatı olduğu yerde kurun.
• Sahiplik birincilden, erişim ikisinden: en kısıtlayıcı olan kazanır.
• Etkin olmayanı yok olandan ayırın ve saklamayı bir iş kuralı yapın.
• Kuralı doğru biçimde ait olduğu en alt yere itin ve meşru geçmişi yeniden yazmak yerine ona bir muafiyet yolu verin.
• Diyagram mimari değildir. Her yapıyı bir iş nedenine kadar geriye izleyebilin.

Bilinmesi Gereken Terimler

Terim	Tek satırda
Meta veri odaklı	Nesneler ve alanlar yeni fiziksel tablolar değil, platformun çalışma zamanında okuduğu tanımlardır
Çok kiracılılık	Birçok org altyapıyı paylaşır, her biri yalıtılmıştır; tek bir binadaki daireler gibi
Yönetici sınırları	Bir kiracının paylaşılan kaynakları tekeline almasını önleyen sınırlar
Harici nesne	Salesforce Connect aracılığıyla Salesforce’ta gösterilen, her dokunuşta kaynağından getirilen veri
Büyük nesne	Çok büyük, nadiren kullanılan veri için depolama; dizini üzerinden sorgulanır
Kişi hesabı	İşletmeden tüketiciye modeller için bir hesap olarak temsil edilen birey
Tam uyum	Bir standart nesnenin amaçlanan kullanımıyla eşleşen bir iş kavramı
Harici Kimlik	Başka bir sistemin tanımlayıcısını tutan, upsert ve eşleştirme için kullanılan bir alan
Upsert	Kayıt varsa güncelle, yoksa oluştur
Arama ilişkisi	Alt kaydın kendi sahibini ve hayatını koruduğu bir ilişki
Ana-ayrıntı	Alt kaydın üst kayda ait olduğu bir ilişki: devralınan sahip ve paylaşım, zincirleme silme, toplama özetleri
Mantıksal bağlantı nesnesi	Modelleme fikri: nasıl kurulmuş olursa olsun, iki nesneyi çoka-çok bir ilişkide birleştiren ve kendi özniteliklerini taşıyan bir nesne
Salesforce bağlantı nesnesi (Salesforce Junction Object)	Salesforce’un “junction object” ile kastettiği: iki ana-ayrıntı ilişkisi olan bir özel nesne
Birincil ve ikincil ana kayıt	Bir Salesforce bağlantı nesnesinin ilk oluşturulan ana-ayrıntısı (sahip, görünüm, bölüm) ve ikincisi (rapor kapsamı; ilki kaldırılırsa birincil olur)
Hiyerarşik ilişki	Yalnızca Kullanıcı nesnesinde olan, Manager gibi, aynı kullanıcıya geri dönemeyen özel bir arama ilişkisi
Ad alanı öneki	Yönetilen bir paketin nesnelerinde ve alanlarında satıcının öneki, örneğin abc__Inspection__c
Paylaşım tablosu	Bir kaydın paylaşımının çoğunu tutan, kullanıcı ya da grup başına bir satır ve nedeniyle birlikte paylaşım nesnesi (AccountShare, Truck__Share)
Toplama özeti	Ana kayıtta, ayrıntılarını sayan, toplayan ya da en küçük veya en büyük değerini bulan bir alan
Veri çarpıklığı	Tek bir üst kaydın ya da tek bir sahibin altında çok fazla kayıt; kilitlere ve uzun paylaşım yeniden hesaplamalarına yol açar
Üye tabanlı / oturum tabanlı	Harici kullanıcı başına ya da her ay oturum başına ödemek
Tutarlılık merdiveni	Alan türünden otomasyona kadar veri kurallarını uygulayan katmanlar
Kısıtlı seçim listesi	Hangi kaynaktan gelirse gelsin listesinde olmayan her değeri reddeden bir seçim listesi
Veri sınıflandırması	Sahip, kullanım, hassasiyet ve uyumluluk kategorisi için alan meta verisi

Kendinizi Sınayın

Kursun tarzında kısa senaryolar. Açmadan önce yanıtınıza karar verin.

1. Kullanıcıların, ERP'nin sahip olduğu ve gün boyu güncellediği sipariş ayrıntılarını görmesi gerekiyor. Onları Salesforce'ta düzenlemiyorlar. İçeri kopyalamalı mı, kopyalamamalı mı?

Onlara başvurun: Salesforce Connect aracılığıyla harici nesneler, eşitlenecek bir kopya olmadan ERP’yi gerçeğin kaynağı olarak tutar. Her görüntülemenin bir dış çağrı yaptığını, dolayısıyla gecikmenin ve ERP’nin erişilebilirliğinin önemli olduğunu ve bunun yoğun düzenleme ya da raporlamadan çok okuma erişimine uyduğunu kabul edin. Başvurulan bölümünü yeniden okuyun.

2. İş birimi distribütörleri, tedarikçileri ve perakende ortaklarını takip etmek istiyor. Üç özel nesne mi?

Hayır. Hepsi şirkettir; dolayısıyla Hesap tam bir uyumdur; farklı adlar bir tür, bir kayıt türü ya da bir ilişkiyle taşınan rollerdir. Tam Uyum Testi bölümünü yeniden okuyun.

3. Bir tasarım Fırsat kullanıyor, ama veriye ihtiyaç duyan insanların çoğunun Salesforce Platform ya da Customer Community lisansı var. Şimdi ne olacak?

Bu lisanslar Fırsat’ı kullanamaz; dolayısıyla lisans mimari bir kısıttır: farklı lisanslar alın, deneyimi taşıyın ya da genellikle bir özel nesneye doğru yeniden tasarlayın. Şimdi Her Şeyi Karmaşıklaştırayım: Lisanslar bölümünü yeniden okuyun.

4. ERP hesaplara gecelik güncellemeler gönderiyor. Entegrasyon, Salesforce kimliklerini sorgulamadan doğru kaydı nasıl bulmalı?

ERP’nin müşteri numarasını bir Harici Kimlik alanında saklayın ve onun üzerinden upsert yapın: bulunursa güncelle, bulunmazsa oluştur. Alt kayıtlar da üst kayda Harici Kimliği üzerinden işaret edebilir. Harici Kimlikler bölümünü yeniden okuyun.

5. Bir Teslimat Kalemi teslimatı olmadan var olamaz, asla taşınmaz ve kendine ait bir sahibe ihtiyaç duymaz. Bir Teslimat rotaya konmadan önce vardır ve başka bir rotaya taşınabilir. Her biri için hangi ilişki?

Teslimat Kalemi’nden Teslimat’a: ana-ayrıntı (ömür boyu üst kayda aittir, erişimi devralır, silmede zincirleme olarak silinir). Teslimat’tan Rota’ya: arama ilişkisi (kendi hayatı var, başta isteğe bağlı, taşınabilir ve bir rotayı silmek asla teslimatları silmemelidir). İş İlişkisiyle Başlayın bölümünü yeniden okuyun.

6. Bir entegrasyon günde 3.300 teslimat oluşturuyor; hepsinin sahibi, hiyerarşinin ortasında bir rolü olan entegrasyon kullanıcısı. Risk nedir ve çözüm ne?

Sahiplik çarpıklığı: 10.000 kaydı geçince o kullanıcıyı taşımak ya da gruplarını değiştirmek uzun paylaşım yeniden hesaplamalarını tetikler. Erişim için önemliyse sahipliği yayın; değilse entegrasyon kullanıcısını rol hiyerarşisinin dışında ya da en üstte tek başına bir rolde ve paylaşım kurallarının kullandığı grupların dışında tutun. Sahiplik Bir Ölçek Sorununa Dönüşebilir bölümünü yeniden okuyun.

7. Bir doğrulama kuralı ekliyorsunuz ve 20.000 eski kayıt onu ihlal ediyor. Bir kullanıcı bunlardan birinde telefon numarasını düzenliyor ve kaydetme başarısız oluyor. Kural ne yapmalıydı?

Yalnızca neyin doğru olması gerektiğini değil, ne zaman uygulanacağını da söylemeliydi: ilgili alanlarda ISNEW() ya da ISCHANGED() ile kapsamını sınırlayın ve kuraldan önce var olan kayıtlara, geçmişlerini yeniden yazmak yerine bilinçli bir muafiyet yolu verin. Eski Kayıt Sorunu bölümünü yeniden okuyun.

8. İş birimi her teslimat fotoğrafının “Salesforce'ta” olmasını istiyor: yılda dört beş milyon, yüzde 30 büyüyerek. Ne önerirsiniz?

Erişimi depolamadan ayırın. Dosyaları çekirdek org’un dışında, bu hacim için inşa edilmiş depolamada tutun ve kullanıcıların onları bulup görebilmesi için Salesforce’ta bir referans, bir sayı ya da bir dizin kaydı tutun. Fotoğraflar bölümünü yeniden okuyun.

9. Bir Ekip Atamasının Ekip (önce oluşturuldu) ve Kamyon ile ana-ayrıntı ilişkileri var. Bir sevk görevlisi ekibi görebiliyor ama kamyonu göremiyor. Ekip Atamasını görebilir mi?

Hayır. Ekip birincildir; dolayısıyla atamaya sahibini ve görünümünü verir, ama erişim iki üst kaydı da gerektirir: sevk görevlisinin, her ana-ayrıntı alanının Sharing Setting’inin (Paylaşım Ayarı) istediği düzeyde ekibe ve kamyona erişimi olmalıdır. En kısıtlayıcı olan kazanır. İki Üst Kayıt Genişlik bölümünü yeniden okuyun.

10. Bir ortak bir yük listesi dosyasını yeniden gönderiyor ve aynı müşteri dosyada iki kez görünüyor. Hesap'ta engellemeye ayarlanmış bir yinelenen kayıt kuralınız var. Güvende misiniz?

Yalnızca yinelenen kayıt kuralıyla değil. Aynı anda kaydedilen kayıtlar birbiriyle değil, yalnızca Salesforce’ta zaten olan kayıtlarla karşılaştırılır; dolayısıyla iki satır da geçebilir. Benzersizliği alana kadar aşağı itin: platformun her kaydetmede denetlediği benzersiz bir Harici Kimlik; böylece yalnızca biri kazanır. Dördüncü Basamak: Yinelenen Kayıt Kuralları ve Ya Hep Ya Hiç bölümlerini yeniden okuyun.

Daha Fazlası

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (İngilizce, kontrol tarihi 2026-09-25): hedeflerin ve ağırlıklarının resmî listesi. Sınava kaydolmadan önce her zaman güncel sürümü kontrol edin.
• Her modülün kendi Daha Fazlası kısmı, platform olgularının arkasındaki Salesforce belgelerini kontrol edildikleri tarihle birlikte listeler.